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

[Camm Maguire <camm at enhanced dot com>]

Greetings, and thank you again for your very helpful feedback!

Alan Modra <amodra@bigpond.net.au> writes:

> 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.
> 

OK, this is good to know, but it still presents me with the following
problems

1) finding the reserved area size
2) finding the plt entry size
3) handling non-elf (gcl works on windows and macosx too)
4) ensuring that the above mapping is the case on all architectures
   and continues to be.

> 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.
> 

This is the approach I've taken so far, but it suffers from the
following lesser weaknesses:

1) On sparc, there are symbols like .div which cannot be written as C
   identifiers.  Apparently a similar problem on mips
2) I have to assume that the linker will never axe my symbol values in
   the future as long as these addresses are taken in the code.

> I really think you'd be better off compiling your modules to shared
> libs, and using dlopen.
> 

Unfortunately impossible.  dlopen, while nice suffers from the
following difficulties:

1) One cannot link persistently and incrementally (i.e. one cannot
   save dlopened objects in an image to be executed later)
2) One must maintain an open file handle for each object (axiom for
   example needs to load more objects than the typical maximum open
   file descriptor resource will allow.  Users might be able to get
   more, but on autobuilders this is quite difficult.)

Thankfully, I believe Peter Wood has suggested the best option, on
which I would greatly appreciate your thoughts:

Briefly, export a linker map via -Wl,-Map foo, parse the .plt section
into a C function which looks up an address from a symbol name string,
relink, and repeat until the map file does not change.  I'm hoping the
following will be true:

1) As the -Map option is well defined, the linker will continue to
   support this output in the future (with no major change in format) 

2) The .plt addresses in the map file are and will continue to be the
   same as the corresponding addresses in the executable.

3) the .plt section contains all effective addresses for undefined
   symbols which could be referenced from a compiled object making
   explicit use of no other functions than available to the main
   program in normal C fashion.  

4) That 3) is true for basically all backends, at least all Linux elf,
   windows, and macosx.


Thanks again!


> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah