This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: IA64 symbol addresses always 0?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: binutils at sources dot redhat dot com
- Cc: Ian Wienand <ianw at gelato dot unsw dot edu dot au>
- Date: Tue, 6 Jan 2004 09:36:26 -0500
- Subject: Re: IA64 symbol addresses always 0?
- References: <20031222062620.GC31201@cse.unsw.EDU.AU> <20040103121902.GB11435@bubble.modra.org>
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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer