Re: [RFC PATCH 1/4] [BFD][LD] Fix linker error when using NT weak externals

[Octavian Purdila <octavian dot purdila at intel dot com>]

On Mon, Oct 26, 2015 at 3:33 AM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Oct 23, 2015 at 03:30:33PM +0300, Octavian Purdila wrote:
>> On Fri, Oct 23, 2015 at 3:06 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Fri, Oct 23, 2015 at 10:08:37AM +0300, Octavian Purdila wrote:
>> >> To clarify the point you where making earlier, why is strong undefined
>> >> preferred over weak undefined? Could you give me an example how
>> >> changes this will affect the linker? To me they are quite similar.
>> >
>> > A weak undefined symbol won't cause an object to be extracted from an
>> > archive, nor will it cause an undefined symbol error.  If you have
>> > both strong and weak undefined symbol references you want the strong
>> > undefined to dominate.  The presence of the weak undefined symbol
>> > should not stop the linker from reporting an error about the strong
>> > undefined symbol if it should not be resolved.  Similarly for archive
>> > extraction.
>> >
>> >> To me, the cleanest solution to handler NT weak externals is to use a
>> >> different BSF_ flag, link_row, link_action, different link hash type,
>> >> etc. This way we can easily differentiate between NT weak externals
>> >> and regular weak symbols and avoid changing existing linker behavior.
>> >> Would that be acceptable?
>> >
>> > I think that adding a new BSF flag and hash type would be more work
>> > than you realize, so no, that is not a good idea.  I find it hard to
>> > credit that a weak function definition results in weak undefined
>> > symbol rather than a weak defined symbol.  That sounds like a compiler
>> > or assembler bug to me.
>> >
>>
>> According to PE COFF standard [1] section 5.5.3:
>>
>>  âWeak externalsâ are a mechanism for object files allowing
>> flexibility at link time. A module can contain an unresolved external
>> symbol (sym1), but it can also include an auxiliary record indicating
>> that if sym1 is not present at link time, another external symbol
>> (sym2) is used to resolve references instead.
>>
>> If a definition of sym1 is linked, then an external reference to the
>> symbol is resolved normally. If a definition of sym1 is not linked,
>> then all references to the weak external for sym1 refer to sym2
>> instead. The external symbol, sym2, must always be linked; typically
>> it is defined in the module containing the weak reference to sym1.
>>
>> Weak externals are represented by a Symbol Table record with EXTERNAL
>> storage class, UNDEF section number, and a value of 0. The
>> weak-external symbol record is followed by an auxiliary record with
>> the following format:
>>
>> [1] http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfeae4b45/pecoff.doc
>
> I see, so they do have a definition but need to be treated as
> undefined until all other symbols have been loaded.  As you may have
> guessed I'm not a COFF linker expert but if I had to implement
> support for this symbol type, I'd be modifying cofflink.c.  Detect
> when you're merging a new weak external with an existing undefined or
> undefweak and modify the existing symbol to be weak external.  If
> merging an existing weak external with a new undefined or undefweak,
> simply ignore the new symbol.
>

Make sense. Thanks for the help Alan, I'll try it out and have a new
patch set for review soon.