This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: forward references in equates


On Thu, Sep 15, 2005 at 03:44:16PM +0200, Jan Beulich wrote:
> - 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)

Well, you would want to copy the symbol when it is redefined, not when
it is used, and be careful exactly when to copy.  Otherwise forward
references could stay undefined.

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

Agreed.  I mentioned pr288 because it shows a case where no relaxation
or other adjustments to dot are done, yet gas doesn't currently see
".-_start" as being absolute after the .balign.

> 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

Hmm, the testcase I added to pr288 doesn't show much because you now
need another
	.set x,.-_start
	.long x
at the end to see anything surprising.  As you say the result isn't like
the original bug report, so something must have changed in the way these
expressions are resolved.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]