This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [hjl@valinux.com: Re: An ELF/PPC patch for ld/testsuite]
- To: geoffk at cygnus dot com
- Subject: Re: [hjl@valinux.com: Re: An ELF/PPC patch for ld/testsuite]
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 19 Oct 2000 12:55:46 -0700
- CC: hjl at valinux dot com, binutils at sources dot redhat dot com
- References: <20001019093528.B607@valinux.com> <200010191943.MAA00877@geoffk.org>
Date: Thu, 19 Oct 2000 12:43:12 -0700
From: Geoff Keating <geoffk@cygnus.com>
- by creating a non-PIC shared object without a load offset, which
causes it to be loaded just under the application at
0x0FFFsomething, and having it branch to an undefined weak symbol
which means location 0. non-PIC code using undefined weak symbols
is not supported on powerpc because it can't work.
This could be fixed by having the linker permit a relocation to an
undefined weak symbol even if that relocation appears to be out of
range. The presumption is that the application will not actually call
such a symbol.
The other restriction is a generic ELF one, which is that non-PIC
applications cannot reliably reference undefined weak symbols. The
symbols will sometimes appear to be zero and sometimes not.
I don't understand this. An undefined weak symbol should always
appear to be zero. In what circumstance would that not be true? I
think I can write a non-PIC application which uses undefined weak
symbols.
if (&foo) foo();
Ian