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

[Richard Sandiford <rdsandiford at googlemail dot com>]

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

Richard