Re: ld from 2.14.90.0.8 puts no value into undefined symbols

[Camm Maguire <camm at enhanced dot com>]

Greetings, and thanks for your helpful reply!

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

> On Thu, Feb 26, 2004 at 07:10:12PM -0500, Camm Maguire wrote:
> > Greetings! In 2.14.90.0.7 and earlier, I'd get a symbol table that
> > looked like
> > 
> > objdump -x foo_good_raw |grep UND
> > 0804a7dc       F *UND*	00000018              __gmpz_fdiv_q_2exp
> > 0804a7ec       F *UND*	00000030              __gmpz_set_si
> > 0804a7fc       F *UND*	0000003e              usleep@@GLIBC_2.0
> > 0804a80c       F *UND*	00000026              cos@@GLIBC_2.0
> > 0804a81c       F *UND*	0000003a              rename@@GLIBC_2.0
> > 0804a82c       F *UND*	0000006d              ferror@@GLIBC_2.0
> > 0804a83c       F *UND*	00000053              sigaction@@GLIBC_2.0
> > ...
> > 
> > Now I get
> > 
> > objdump -x foo_bad_raw | grep UND
> > 00000000       F *UND*	00000018              __gmpz_fdiv_q_2exp
> > 00000000       F *UND*	00000030              __gmpz_set_si
> > 00000000       F *UND*	0000003e              usleep@@GLIBC_2.0
> > 00000000       F *UND*	00000026              cos@@GLIBC_2.0
> > 00000000       F *UND*	0000003a              rename@@GLIBC_2.0
> > 00000000       F *UND*	0000006d              ferror@@GLIBC_2.0
> > 00000000       F *UND*	00000053              sigaction@@GLIBC_2.0
> 
> Yes, this is a result of a fairly recent optimization.  See
> http://sources.redhat.com/ml/binutils/2004-01/msg00025.html and
> following posts.

Thanks.  I'm sure there is some good, apparently performance related,
reason for this change in general.  It does require a change on the
part of gcl/maxima/acl2/axiom, and I'd like to make it as robust as
possible. 

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

GCL has to be able to compile user defined functions into .o objects,
load and relocate these .o files into memory allocated in the running
executable's .data section, make the area executable, and continue the
same session with the object made immediately accessible.  Much like
dlopen, except that lisp users and programs frequently need to dump
the image with unexec and restart sometime later, with the object
still in place.  These .o files can have a few symbols referring to
functions in external shared libraries, e.g. _setjmp, __moddi3, some
math functions -- some of these due to explicit mention in the source
for the .o file, and some not explicitly mentioned but written in by
gcc.  GCL has to know where to relocate these symbols within a running
image already having access to them.

Suggestions for the most robust and platform independent way we can
determine these addresses are most appreciated.  It is already
apparent that the symbol value in the executable is not the robust
solution we were hoping for.

Take care,

> -- 
> Alan Modra
> IBM OzLabs - Linux Technology Centre
> 
> 
> 

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