public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mischa Baars <mjbaars1977@gmail.com>
To: gcc-help@gcc.gnu.org
Cc: Andrew Haley <aph@redhat.com>
Subject: Re: indexing arrays
Date: Mon, 18 Nov 2013 11:36:00 -0000	[thread overview]
Message-ID: <5289F4D8.6000401@gmail.com> (raw)
In-Reply-To: <5289E4A0.9030807@redhat.com>

On 11/18/2013 10:57 AM, Andrew Haley wrote:
> On 11/18/2013 03:47 AM, Mischa Baars wrote:
>> On 11/17/2013 11:05 PM, Florian Weimer wrote:
>>> * Mischa Baars:
>>>
>>>> Please have a look at the following example, and let me know what
>>>> you think.
>>> The code doesn't contain any comments, so we don't know what you're
>>> trying to do.
>> The assembly file does, if you would just look at it.
>>
>> As you can see, the 'ebx' register is unprotected when the function is
>> called from a location other than 'main'. Normally I shouldn't be able
>> to modify the array index from the assembly.
> You're doing it wrong.  It is the job of the called function to save and
> restore %ebx:
>
> %ebx     As described below, this register serves as the global offset
>           table base register for position-independent code. For
>           absolute code, %ebx serves as a local register and has no
>           specified role in the function calling sequence. In either
>           case, a function must preserve the register value for the
>           caller.
>
> Andrew.
>
>
> http://www.sco.com/developers/devspecs/abi386-4.pdf

I see what you are pointing at (p.37), but it also says "DRAFT COPY" :)

As you see from the program output, the 'ebx' register IS preserved when 
the 'npx_on_double()' function is called from 'main()', but the 'ebx' 
registers IS NOT preserved when the 'npx_on_double()' function is called 
from another function like 'npx_on_complex()'.

This makes writing low-level functions very sensitive to errors. You 
would only notice that your function is in error, when it is called from 
other functions than 'main()', which is most likely not the first thing 
you do. In my case, that's almost three years later.

Mischa.

  reply	other threads:[~2013-11-18 11:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-17  9:47 Mischa Baars
2013-11-17 22:05 ` Jonathan Wakely
2013-11-18  0:27 ` Florian Weimer
2013-11-18  7:57   ` Mischa Baars
2013-11-18 10:29     ` Andrew Haley
2013-11-18 11:36       ` Mischa Baars [this message]
2013-11-18 14:12         ` Andrew Haley
2013-11-18 14:15           ` Mischa Baars
2013-11-18 15:29             ` Andrew Haley
2013-11-18 17:46               ` Mischa Baars
2013-11-19 11:18                 ` Rob
2013-11-18 19:28         ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5289F4D8.6000401@gmail.com \
    --to=mjbaars1977@gmail.com \
    --cc=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).