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

[H.J. Lu]

On Wed, Apr 1, 2009 at 2:51 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>

See elf_link_add_object_symbols and _bfd_elf_merge_symbol
for details.



-- 
H.J.