Re: Your GAS change caused a testsuite regression for cris-elf

["Jan Beulich" <JBeulich at novell dot com>]

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