Re: forward references in equates

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

>I think that this would be a positive change, and I wouldn't worry too
>much about backward compatibility.  However, bear in mind that the
>primary purpose of gas is to assemble gcc output.  You wouldn't want
to
>significantly slow down assembly of gcc output.

Sure. But on the other hand compilers rarely emit very complex
expressions.

>Worse, resolving some
>expressions early and making that a documented gas behaviour, will no
>doubt result in bug reports about similar but subtly different cases.

I'm actually not thinking of resolving expressions as early as
possible, but rather as late as possible, just with the constraints that
when

- an absolute value is needed (and the expression is not O_constant),
then obtain the current value (without tying the expression value to
that current one)

- an expression gets used but no absolute value is needed, all known
operands must be tied to their current values (which means all symbols,
because they can potentially get redefined, must get copied rather than
use in-place; here a mechanism to identify a symbol can't change its
value would be rather helpful - I originally though .equiv would serve
that purpose [i.e. protect the symbol from getting re-defined], but
sadly that's not the case, as much as normal symbols [resulting from
labels] aren't protected from getting redefined through .equ)

>What looks obviously an absolute expression to a programmer might not
be
>so easy to resolve in gas, due to gas frags.  See pr288. 

I'm not sure the PR can be addressed by resolving expressions earlier
(I rather think this would get fixed with the second of the two
alternatives mentioned above). But that may be because either

- I have a problem reproducing the original issue (the mail referred to
shows all different values after the .balign, but when I try this on x86
I get all identical values), or
- I don't understand what you're trying to say there (especially about
the comment being wrong - I don't think it is, because the code really
seem to take care to only resolve O_subtract when both operands are in
the same frag), or 
- the description is misleading (the problem seems to be not with
absolute symbols/expressions [which get generated before the .balign],
but with the too-late resolution of non-absolute ones [after the .balign
the values associated with the .long-s are O_subtract expressions

>Consider also
>"x - x" where x is an undefined symbol, and the whole class of "x -
y"
>where x and y possibly involve undefined syms but are equal if fully
>resolved.

Sure, but that should automatically be taken care of with the approach
outlined above.

Jan