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: Octavian Purdila <octavian dot purdila at intel dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Mon, 26 Oct 2015 12:04:42 +0200
- 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> <20151026013356 dot GY13961 at bubble dot grove dot modra dot org>
On Mon, Oct 26, 2015 at 3:33 AM, Alan Modra <email@example.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 <firstname.lastname@example.org> 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.
Make sense. Thanks for the help Alan, I'll try it out and have a new
patch set for review soon.