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


>>> Alan Modra <amodra@bigpond.net.au> 16.09.05 04:25:12 >>>
>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.

That would have been nice, but doesn't work. While it resolves the
problem in PR/288, it doesn't address the problem outlined in my
original mail. Specifically, for

 .equiv two, 2*one
 .equ one, 1
 .equiv three, 3*one

 .data

	.byte	one
	.byte	two
	.byte	three

 .equ one, -1
	.byte	one
	.byte	two
	.byte	three

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'). It seems clear
to me that only the snapshotting-the-expression approach can address
this. With the earlier mentioned change to disallow re-assigning values
to 'normal' and .equiv-produced symbols it would seem to me that not too
much copying would need to happen (because with that it'd be known that
only .equ-produced symbols can ever change, and hence within any
expression only those need to be cloned; obviously an expression tree
could propagate upwards the fact that any sub-expression actually uses
such a 'floating' symbol son that in the common case no descending into
the tree would be necessary).

While working out the changes needed for the approach suggested by you
I unfortunately found another issue: In

 .equiv x, y-z
 .equiv x, 1

gas would not report a redefinition of x, since for expressions used as
the assigned values the symbol gets set to undefined_section rather than
expr_section. Changing this fixes this problem and also doesn't, for
x86, show any other regressions in the testsuite, but I'm a little
worried that there might be dependencies on undefined_section being used
in this case somewhere. Should I still submit a patch for that (and
leave it to the future to locate any potential problems resulting from
that), or do you have an idea how the safeness of such a change could be
proven and/or why undefined_section was used there in the first place
(introduced by you in 1.95/1.94.2.1)?

Thanks, Jan


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