RFC/A: Add a bfd hook for defining common symbols

H.J. Lu hjl.tools@gmail.com
Wed Apr 1 21:51:00 GMT 2009


On Wed, Apr 1, 2009 at 1:37 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Thanks for the reply.
>
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>> On Wed, Apr 1, 2009 at 12:28 PM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> The XCOFF linker uses XCOFF_DEF_REGULAR to check whether a symbol
>>> has a regular definition.  xcofflink.c:xcoff_post_gc_symbol therefore
>>> checks for common symbols that were defined by the linker:
>>>
>>>  /* If this is a final link, and the symbol was defined as a common
>>>     symbol in a regular object file, and there was no definition in
>>>     any dynamic object, then the linker will have allocated space for
>>>     the symbol in a common section but the XCOFF_DEF_REGULAR flag
>>>     will not have been set.  */
>>>  if (h->root.type == bfd_link_hash_defined
>>>      && (h->flags & XCOFF_DEF_REGULAR) == 0
>>>      && (h->flags & XCOFF_REF_REGULAR) != 0
>>>      && (h->flags & XCOFF_DEF_DYNAMIC) == 0
>>>      && (bfd_is_abs_section (h->root.u.def.section)
>>>          || (h->root.u.def.section->owner->flags & DYNAMIC) == 0))
>>>    h->flags |= XCOFF_DEF_REGULAR;
>>>
>>> But this happens too late for things like xcoff_mark_auto_exports.
>>>
>>> We could just put this code in a function and use it instead of testing
>>> XCOFF_DEF_REGULAR directly.  That seems a bit messy though, and I don't
>>> really like this idea of detecting what the linker has done after the fact.
>>>
>>> Another alternative is to add a linker emulation hook.  But we'd
>>> then be exposing XCOFF_DEF_REGULAR outside BFD, which doesn't seem
>>> very clean either.
>>
>> FWIW, ELF linker emulation includes "elf-bfd.h" and uses plenty of
>> BFD/ELF things. I don't see why you can't do it for XCOFF. You don't
>> need to access XCOFF_DEF_REGULAR directly from linker. A macro
>> defined in BFD should work for you.
>
> True, but I was more meaning: it exposes the _existence_ of
> XCOFF_DEF_REGULAR outside bfd.  That is, it exposes the fact
> there's this magic bfd function (or bfd macro) that has to be
> called after defining a common symbol on XCOFF, even though
> no such thing is needed for other targets.  The reason we need
> the hook isn't that XCOFF common symbols are any different from
> other targets' common symbols.  The reason is simply that we
> need to do some bfd-internal, XCOFF-specific book-keeping
> after defining a symbol.
>
> More generally, my attitude was that code should be in bfd if it
> represents a general concept that does not depend on information that
> only the linker proper has access to.  I think that's the case here.
> The current code is changing the type of a bfd hash table entry
> "behind bfd's back".
>

ELF backend also does many common symbol related book-keeping
things. Why can't XCOFF backend use similar hooks.


-- 
H.J.



More information about the Binutils mailing list