gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: ld from 2.14.90.0.8 puts no value into undefined symbols


From: Alan Modra
Subject: [Gcl-devel] Re: ld from 2.14.90.0.8 puts no value into undefined symbols
Date: Tue, 2 Mar 2004 10:19:27 +1030
User-agent: Mutt/1.4i

On Mon, Mar 01, 2004 at 11:53:58AM -0500, Camm Maguire wrote:
> Alan Modra <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]