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

[Alan Modra <amodra at gmail dot com>]

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.

-- 
Alan Modra
Australia Development Lab, IBM