This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld from 2.14.90.0.8 puts no value into undefined symbols
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Camm Maguire <camm at enhanced dot com>
- Cc: binutils at sources dot redhat dot com, gcl-devel at gnu dot org
- Date: Tue, 2 Mar 2004 10:19:27 +1030
- Subject: Re: ld from 2.14.90.0.8 puts no value into undefined symbols
- References: <E1AwVa0-0007GA-00@intech19.enhanced.com> <20040301151508.GC2551@bubble.modra.org> <5465doy0d5.fsf@intech19.enhanced.com>
On Mon, Mar 01, 2004 at 11:53:58AM -0500, Camm Maguire wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> > On Thu, Feb 26, 2004 at 07:10:12PM -0500, Camm Maguire wrote:
> > > I need to get the .plt address back somehow
> >
> > Why? Perhaps you could look at plt relocs.
>
> Are you suggesting a solution, or a reason why I should not need the
> addresses? If the former, could you kindly point me to a URL? I've
> done a quick search and can only find references to plt reloc
> errors.
I was asking why you needed the undefined symbols to point into the
plt, which you have explained. (I think you explained the gcl scheme
some time ago, but I'd forgotten the details.) I was also suggesting
a solution.
If you look at a typical x86 executable with readelf -r, you'll see
something like the following:
Relocation section '.rel.plt' at offset 0xdd8 contains 82 entries:
Offset Info Type Sym.Value Sym. Name
0814cc44 00000107 R_386_JUMP_SLOT 00000000 ferror
0814cc48 00000207 R_386_JUMP_SLOT 00000000 strncat
0814cc4c 00000307 R_386_JUMP_SLOT 00000000 strchr
[snip]
The list of relocations will allow you to reconstruct how the plt is
laid out, since they correspond 1-1 with plt slots (except for any
reserved entries at the beginning). So you know from the above, that
the first plt entry is for ferror, the second for strncat, and so on,
I think this is true for other architectures too, but note that size of
plt entries and size of the reserved area varies from one architecture
to another.
You could also disable Jakub's optimization
http://sources.redhat.com/ml/binutils/2003-11/msg00258.html by taking
the address of all functions referenced by your executable.
I really think you'd be better off compiling your modules to shared
libs, and using dlopen.
--
Alan Modra
IBM OzLabs - Linux Technology Centre