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

[Camm Maguire]

Greetings, and thanks for the discussion.  It is *very* helpful.

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

> On Tue, Mar 02, 2004 at 06:47:35PM -0500, Camm Maguire wrote:
> > 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.
> 
> You're relying on a backend defining a symbol (at least internal to ld)
> in the plt for unresolved functions.  This is not the case for all
> architectures.  I think you'll find that at least powerpc64, ia64, mips
> and hppa don't do so.  Of course, using nm on these architectures would
> not have worked either.

Just checked (on ia64 at least) and you're right -- the .plt section
of the map is empty.  Interestingly enough, it is also exactly
mips(el), hppa, ia64 with the addition of alpha among the Debian
architectures which do not support the bfd routine
bfd_get_relocated_section_contents.  I'm wondering if this is a
coincidence. 

In any case, on these architectures gcl has been limited to a very
awkward dlopen based scheme already for some time, which, among other
items, means that these platforms cannot completely autobuild axiom
with its databases, forcing difficult and fragile workarounds.

I'm also wondering if there is any other point in the executable which
could be used as a launch point to reach these symbols, preferably a
point which would be reflected in the map file.  More fundamentally to
the task at hand, is there a somewhat simple way to fix
bfd_get_relocated_section_contents on these platforms?  We had assumed
the answer was no and that we would have to eventually rewrite our bfd
relocation code to use what appears to be a newer but more complicated
interface based on *relocate_section.

> 
> It would be possible to modify ld to print the plt layout on all
> architectures..
> 

If this were done, would it function in the same way as it does on the
other platforms?  If so, and if it is agreeable to the binutils
developers, some of us working on gcl might be able to contribute the
patch. 

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