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

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.