This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]