indexing arrays

indexing arrays

[Mischa Baars]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Hi,

Please have a look at the following example, and let me know what you think.

Hope this is the right mailing list.

Regards,
Mischa.

[-- Attachment #2: 2013111500 - gnu compiler - indexing arrays.tar.gz --]
[-- Type: application/x-gzip, Size: 10240 bytes --]

Re: indexing arrays

[Jonathan Wakely]

Yes, it's the right mailing list, but you could just post the code in
your email, instead of a compressed archive. You could also take a
little more time to explain what you're asking about. What result are
you expecting? What result do you get? Why should we waste our time
trying to work out what you're asking about, if you can't be bothered
to explain yourself properly?

Re: indexing arrays

[Florian Weimer]

* 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.

Re: indexing arrays

[Mischa Baars]

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.

Re: indexing arrays

[Andrew Haley]

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

Re: indexing arrays

[Mischa Baars]

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.

Re: indexing arrays

[Andrew Haley]

On 11/18/2013 11:07 AM, Mischa Baars wrote:
> 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.
>>
>> http://www.sco.com/developers/devspecs/abi386-4.pdf
> 
> I see what you are pointing at (p.37), but it also says "DRAFT COPY" :)

That isn't going to change any time soon.

> 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.

No-one can write reliable code by trying something and seeing if it
works.  You have know understand what you're doing.  When writing
assembly code it's your job to know the ABI, and to follow the rules.
Do that, and you'll be fine.

Andrew.

Re: indexing arrays

[Mischa Baars]

On 11/18/2013 12:35 PM, Andrew Haley wrote:
> On 11/18/2013 11:07 AM, Mischa Baars wrote:
>> 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.
>>>
>>> http://www.sco.com/developers/devspecs/abi386-4.pdf
>> I see what you are pointing at (p.37), but it also says "DRAFT COPY" :)
> That isn't going to change any time soon.

As I understand, you're not willing to consider any alternative to the 
ABI. I understand!

>
>> 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.
> No-one can write reliable code by trying something and seeing if it
> works.  You have know understand what you're doing.  When writing
> assembly code it's your job to know the ABI, and to follow the rules.
> Do that, and you'll be fine.
>
> Andrew.

You seem to have forgotten a couple of my words.

It took me two or three years to realize there was this minor 
misconception in code that I was already working with, the construction 
the compiler is using seems a little sensitive to errors.

Mischa.

Re: indexing arrays

[Andrew Haley]

On 11/18/2013 02:12 PM, Mischa Baars wrote:
> On 11/18/2013 12:35 PM, Andrew Haley wrote:
>> On 11/18/2013 11:07 AM, Mischa Baars wrote:
>>> 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.
>>>>
>>>> http://www.sco.com/developers/devspecs/abi386-4.pdf
>>> I see what you are pointing at (p.37), but it also says "DRAFT COPY" :)
>> That isn't going to change any time soon.
> 
> As I understand, you're not willing to consider any alternative to the 
> ABI. I understand!

It's not really ours to change.

>>> 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.
>>
>> No-one can write reliable code by trying something and seeing if it
>> works.  You have know understand what you're doing.  When writing
>> assembly code it's your job to know the ABI, and to follow the rules.
>> Do that, and you'll be fine.
> 
> You seem to have forgotten a couple of my words.
> 
> It took me two or three years to realize there was this minor 
> misconception in code that I was already working with, the construction 
> the compiler is using seems a little sensitive to errors.

It's not that I've forgotten, it's that I disagree.  I think that
you're making a fundamental error.  When you're working with low-level
code, everything is very delicate.  It's delicate because it's very
highly-optimized: the ABI is the way it is so that the compiler can
save a few nanoseconds here and there.  Once you say, in effect,
"trust me, I know what I'm doing" you have to be very careful to get
things right.  If you're working in Python or somesuch the compiler
will protect you from such things, but in assembler it's your job to
look after your registers!

In my opinion, the correct response (by which I mean to say, the
response I'd make) in these circumstances would be "Ooops, I messed
up.  Sorry for the noise."

Andrew.

Re: indexing arrays

[Mischa Baars]

On 11/18/2013 03:39 PM, Andrew Haley wrote:
> On 11/18/2013 02:12 PM, Mischa Baars wrote:
>> On 11/18/2013 12:35 PM, Andrew Haley wrote:
>>> On 11/18/2013 11:07 AM, Mischa Baars wrote:
>>>> 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.
>>>>>
>>>>> http://www.sco.com/developers/devspecs/abi386-4.pdf
>>>> I see what you are pointing at (p.37), but it also says "DRAFT COPY" :)
>>> That isn't going to change any time soon.
>> As I understand, you're not willing to consider any alternative to the
>> ABI. I understand!
> It's not really ours to change.
>
>>>> 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.
>>> No-one can write reliable code by trying something and seeing if it
>>> works.  You have know understand what you're doing.  When writing
>>> assembly code it's your job to know the ABI, and to follow the rules.
>>> Do that, and you'll be fine.
>> You seem to have forgotten a couple of my words.
>>
>> It took me two or three years to realize there was this minor
>> misconception in code that I was already working with, the construction
>> the compiler is using seems a little sensitive to errors.
> It's not that I've forgotten, it's that I disagree.  I think that
> you're making a fundamental error.  When you're working with low-level
> code, everything is very delicate.  It's delicate because it's very
> highly-optimized: the ABI is the way it is so that the compiler can
> save a few nanoseconds here and there.  Once you say, in effect,
> "trust me, I know what I'm doing" you have to be very careful to get
> things right.  If you're working in Python or somesuch the compiler
> will protect you from such things, but in assembler it's your job to
> look after your registers!
>
> In my opinion, the correct response (by which I mean to say, the
> response I'd make) in these circumstances would be "Ooops, I messed
> up.  Sorry for the noise."
>
> Andrew.

At least you have the example in case you need it, in my opinion the 
compiler is in error.

Have fun!

Re: indexing arrays

[Ian Lance Taylor]

On Mon, Nov 18, 2013 at 3:07 AM, Mischa Baars <mjbaars1977@gmail.com> wrote:
> On 11/18/2013 10:57 AM, Andrew Haley wrote:
>>
>> http://www.sco.com/developers/devspecs/abi386-4.pdf
>
> I see what you are pointing at (p.37), but it also says "DRAFT COPY" :)

The version on the web site is a draft, but the exact same text
appears in the book "System V Application Binary Interface Intel 386
Processor Supplement" published by AT&T in 1991.


> This makes writing low-level functions very sensitive to errors.

You are correct: writing low-level functions is very sensitive to
errors.

Ian

Re: indexing arrays

[Rob]

On Mon, Nov 18, 2013 at 04:47:01PM +0100, Mischa Baars wrote:
>
> At least you have the example in case you need it, in my opinion the
> compiler is in error.

This isn't even gcc, you're just making noise. Try it with clang or read
the x86_64 ABI.

Surely it's common knowledge that if you're writing assembly, certain
registers are preserved across function calls? What about %ebp?

Compile this file, even on the lowest optimisation level (-O1) using
both gcc and clang, and you'll see that they're explicitly using %ebx to
save the value of `i'. It's not an accident.

int main(void)
{
	int i = save_me();
	f(g(), h());
	return i;
}

Regards,
Rob