This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: forward references in equates
>>> Alan Modra <amodra@bigpond.net.au> 17.09.05 16:14:46 >>>
>On Fri, Sep 16, 2005 at 01:58:19PM +0200, Jan Beulich wrote:
>>
>> .equiv two, 2*one
>> .equ one, 1
>> .equiv three, 3*one
>>
>> .data
>>
>> .byte one
>> .byte two
>> .byte three
>
>I'd be reasonably confortable if gas gave 1, 2, 3 for the above,
That'd be my expectation, too.
>> .equ one, -1
>> .byte one
>> .byte two
>> .byte three
>
>but what should these be? I'd be inclined to say -1, 2, 3. Are you
>proposing that the last three values be -1, -2, -3? That would be
>changing the meaning of .equiv, I think.
I'm not as determined about the third value, but the second value
should certainly be -2 (as the definition of two is clearly using a
forward reference).
For the third value, if we don't want to allow this to be -3 here, then
we'll need some other mechanism to allow forcing lazy evaluation of an
expression to meet other assemblers' behavior. ia64 has a == operator to
do that (haven't submitted a patch to support that, yet, because I first
wanted to see where we'd want to go with .equ/.equiv), but having a
directive doing the same would certainly be nice and more consistent
with the rest of gas.
>> without the change the value stored for 'two' in both instances was
>> 0xFE (the final value), while with the change it is now in both
cases
>> 0x02 (the value derived with the first setting of 'one').
>
>Certainly, the current gas behaviour of giving -2 for both instances
of
>"two" is counter-intuitive.
>
>> It seems clear
>> to me that only the snapshotting-the-expression approach can
address
>> this.
>
>I don't think taking a snapshot of the expression is correct. It's
>obviously wrong for an expresion that is undefined at the point where
it
>is used, for example:
>
>str1:
> .byte len
> .ascii "pascal style string"
>len = . - str1 - 1
Oh, certainly, I wasn't explicit about that, but unresolvable
expression clearly shouldn't be snapshot.
Jan