Re: Questions about runtime linking...

[Daniel Jacobowitz <drow at false dot org>]

On Tue, May 18, 2004 at 10:33:10AM -0700, David Daney wrote:
> Background:
> 
> I am running a program on mipsel-linux linked against glibc, libgcj and 
> other shared libraries.  In this program there are several places where 
> tolower(3) is called.  This is converted by gcc into a lookup against a 
> symbol called "__ctype_tolower" that is in libc.so.6.  Since this is 
> mips, the symbol is accessed via the GOT, also this is a very large 
> program so we are in a multi-got situation.  Some of the GOT entries 
> point to the proper place (__ctype_tolower) others point to the wrong 
> place (causing a SIGSEGV when accessed).
> 
> On a version of this program that does not exhibit these problems, If I 
> run objdump -R on the program I get a bunch of relocations against 
> libgcj, but there are none against libc.so.6.
> 
> If I run "objdump -T testapp | grep UND" I get :
> 00520c10      DF *UND*  00000000              _ZN4java4lang4Byte9byteValueEv
> 00000000  w   D  *UND*  00000000              __gmon_start__
> 00520c00      DF *UND*  00000000              _Jv_NewObjectArray
> 00000000      DF *UND*  00000000  GLIBC_2.0   shmat
> 00520bf0      DF *UND*  00000000              
> _ZN4java4util6Arrays6equalsEP6JArrayIcES4_
> 00000000      DO *UND*  00000068              
> _ZN4java5beans21PropertyChangeSupport6class$E
> 00520be0      DF *UND*  00000000              
> _ZN4java4lang12StringBuffer6appendEPNS0_6ObjectE
> 00000000      DF *UND*  00000000              _ZN4java4lang6Thread5startEv
> 00520bd0      DF *UND*  00000000              
> _ZN4java4lang6System6setErrEPNS_2io11PrintStreamE
> 00000000      DO *UND*  00000068              _ZN4java4util5Stack6class$E
> 00000000      DF *UND*  00000000  GLIBC_2.0   read
> .
> .
> .
> Where there are symbols from glibc that are undefined and need fixups.
> 
> Questions:
> 
> What property of a symbol make it appear as a dynamic relocation entry?
> 
> Why don't symbols from glibc appear in the dynamic relocation entries?

Symbols only referenced in the initial GOT do not necessarily appear in
the list of dynamic relocations on MIPS.

This is somewhat horrifying from a cross-platform-consistency
perspective.

> How do I find where the relocations are for the undefined symbols from 
> an objdump -T testapp listing?

Wherever objdump -R says - and also, sort of, at the appropriate offset
in .got determined by the symbol index and the dynamic tags
(DT_MIPS_GOTSYM?  Something like that.)

> And for bonus points:  What would cause glibc's "__ctype_tolower" symbol 
> to appear as a dynamic relocation entry (thus seeming to cause my 
> problems), when normally it does not?

Reference from a secondary GOT?

> I apologize in advance if this is covered in some ELF FAQ somewhere that 
> I have not found.

What linker version are you using?  It sounds like it's 2.14 and you
should try this whole system again using 2.15, where I fixed a number
of multi-GOT bugs.

-- 
Daniel Jacobowitz