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


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

Yes, this would certainly be more efficient. However, this requires
guarantees that there are no places where things expect symbols to have
their values resolved just because resolve_symbol_value() was called
from scanning the global symbol chain(s), as the pre-copy symbols would
be orphaned (unless we'd want to create a new list for them). Inspecting
the places where resolve_symbol_value() gets called I came across on
dubious place in fixup_segment (write.c around line 2156), where it gets
called for fixP->fx_subsy but not for fixP->fx_addsy. It would seem to
me that the call should either be made for both or not at all. Similarly
many of the calls to resolve_symbol_value() in config/tc-*.c seem
pointless, as S_GET_VALUE() already takes care of calling this function
when needed.

Also, wrt. the ability to redefining symbols: After some more thinking
I believe behavior should be changed so that using .equiv (vs. .equ) not
only checks whether the symbol was already defined, but also prevents
the symbol from later getting redefined (and similarly, 'normal' symbols
shouldn't be allowed to be subject of redefinition through .equ).
Implementation-wise I would see this as .equ (and the = assignment
operator) setting a new flag in the symbol stating that it can be
redefined (it would be clear for all other, including the 'normal',
symbols). The check in assign_symbol() would then additionally test that
flag.

Jan


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