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