Re: PATCH: ld/2218: Weak undefined symbol doesn't work properly with PIE

[Alan Modra <amodra at bigpond dot net dot au>]

On Sun, Feb 19, 2006 at 08:02:54PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 20, 2006 at 10:19:39AM +1030, Alan Modra wrote:
> > After giving this some more thought, I'm inclined to say that this patch
> > does not belong in the generic ELF support.  The reason is that the
> > behaviour of weak undefined symbols is not well defined.  At least, I'm
> > not aware of any standard that says an undefined weak sym should be made
> > dynamic when dynamic objects are involved in the link.  I think it would
> > be quite reasonable for an ELF target to choose to resolve undefined
> > weak syms in an executable to zero at link time.
> > 
> > So I think we ought to patch each backend individually, painful as that
> > might be.  Note that many backends already handle undef weak syms
> > specially, eg. calling bfd_elf_link_record_dynamic_symbol for plt and
> > got references (even in non-pie exes).
> 
> I don't think I follow your logic here.  We've got a Linux port to the
> lion's share of architectures that we have an ELF backend and dynamic
> linking for; we're going to end up implementing the same thing in each
> and every one of those backends, to be consistent.
> 
> Are you worried about compatibility with some as-yet-unknown tools that
> don't do this?

Yes, and the possibility that some existing target already handles
undefined weak differently, and will be broken by a patch like HJ's.

>  If so, can we have a backend flag to turn it off, but
> enable it by default and keep the code in common?

We could, but take a look at a typical allocate_dynrelocs function.
Undefined weak are treated specially for plt, got, and when we try to
eliminate copy relocs.  I don't think it makes sense to just handle
undefined weak in pie in generic ELF code without handling the other
cases.   And, since we have quite different plt/got schemes, I think it
will be quite awkward to try to handle them all in generic code.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre