This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: IA64 symbol addresses always 0?
On Tue, 6 Jan 2004, Daniel Jacobowitz wrote:
> On Sat, Jan 03, 2004 at 10:49:02PM +1030, Alan Modra wrote:
> > On Mon, Dec 22, 2003 at 05:26:20PM +1100, Ian Wienand wrote:
> > [snip]
> > > Shouldn't the symbol value be the PLT entry for the relocation?
> > >
> > > This meshes with what I understand of 386 behaviour, where an
> > > R_I386_JUMP_SLOT gives it's value as the PLT entry if I haven't
> > > misunderstood:
> >
> > x86 is really the odd one out, as undefined symbols are normally zero.
> >
> > x86 gives undefined function symbols a value in the plt so that you can
> > load the "address" of the function in an app without needing text
> > relocations. The dynamic linker co-operates with another hack that
> > ensures a shared lib defining the function also gets the same address.
> > This is needed to make function pointer comparisons work between an app
> > and a shared lib. ia64 uses a different scheme for function pointers
> > that doesn't need this hack.
> >
> > Note that CVS x86 ld *doesn't* set all undefined function symbols to
> > their plt entries, only those that have their address taken in the app.
>
> Don't most non-descriptor architectures do this? ARM does, and MIPS
> does (sometimes and sometimes not; I don't remember exactly why but I
> think it's the same if-address-taken). SH does. Even PPC does.
CRIS does too. I'm most interested if there's a port that
*doesn't*, because this behavior is related to a long-standing
CRIS linker bug (now a glibc bug too and they won't revert :-().
(Fix forthcoming in a few days.) The psABI's should say this.
I know the i386 one says this, but I'm unsure whether any other
does.
brgds, H-P