This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]