This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Your GAS change caused a testsuite regression for cris-elf
>>> Alan Modra <amodra@bigpond.net.au> 27.09.05 03:19:32 >>>
>On Mon, Sep 26, 2005 at 02:54:39PM +0200, Jan Beulich wrote:
>> >>> Alan Modra <amodra@bigpond.net.au> 20.09.05 17:05:23 >>>
>> > * read.c (pseudo_set): Don't set undefined symbols to
>> expr_section.
>>
>> I don't think this is correct, as it leads to failure recognizing
the
>> redefinition of x in
>>
>> .equiv x, y
>> .equiv x, 1
>>
>> or, even less logical (because x by the time it gets redefined is
fully
>> resolvable),
>>
>> .equiv x, y
>> .equiv y, 1
>> .equiv x, 1
>>
>> The problem observed by Hans-Peter probably needs to be fixed in
a.out
>> and/or stabs related code.
>
>Given an undefined "y", ".equiv x,y" results in an "x" that is also
in
>some sense undefined. I don't want to break places in gas that use a
>simple test of the section to see whether a symbol is defined or not.
>Fixing a longstanding bug with .equiv by changing the symbol section
>will probably break more than just the aout stabs code.
I'm sorry, but this makes no sense to me. A bug is a bug and should be
fixed. The more that in the second example given y (and thus x) isn't
even 'in some sense undefined'; it's just the case that x never
'learned' that y became defined. Plus it makes it impossible to write
code that supplies a fallback value in case of a symbol being
undefined:
.equiv x, y
.equiv y, 1
.ifndef x
.equiv x, 0
.endif
And finally, in what way is
.equiv x, y-z
.equiv x, 0
different from the first example above? I.e., why is x not 'in some
sense undefined' here?
Jan