This is the mail archive of the
mailing list for the binutils project.
Re: [RFC PATCH 1/4] [BFD][LD] Fix linker error when using NT weak externals
- From: Alan Modra <amodra at gmail dot com>
- To: Octavian Purdila <octavian dot purdila at intel dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 26 Oct 2015 12:03:56 +1030
- Subject: Re: [RFC PATCH 1/4] [BFD][LD] Fix linker error when using NT weak externals
- Authentication-results: sourceware.org; auth=none
- References: <1445530220-4412-1-git-send-email-octavian dot purdila at intel dot com> <1445530220-4412-2-git-send-email-octavian dot purdila at intel dot com> <20151023063913 dot GV13961 at bubble dot grove dot modra dot org> <CAE1zot+sOJZgC3_C-Q3rUEb0Xa20FLoQv0wHqV9bVBKQjoKyBg at mail dot gmail dot com> <20151023120615 dot GX13961 at bubble dot grove dot modra dot org> <CAE1zot+AD5dxyoPo4RxdXamOPw2C5d=+GDHg-JbNo8fxd5wo-g at mail dot 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 <email@example.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  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:
>  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.
Australia Development Lab, IBM