Re: relocation of shared libs not based at 0

[Kevin Buettner <kevinb at redhat dot com>]

On Feb 5,  2:40pm, Paul Koning wrote:

> I'm resurrecting this thread to bring up a problem that's closely
> related.
> 
> On mips-netbsd, even after fixing the relocation problem (e.g., by the
> patch I proposed earlier) gdb still has problems.  Specifically, it
> computes the wrong address for data within the shared library.
> 
> After doing battle with various parts of gdb for quite some time, I
> finally realized what the issue is.  What puzzled me is that it works
> just fine on netbsd-i386.  That finally led me to the answer...
> 
> The reason can be seen by looking at the symbol table.  Here are
> (partial) objdump runs, first for i386, then for mips:
> 
> mainx86/libf3.so:     file format elf32-i386
> 
> SYMBOL TABLE:
> 000006fc l     F .text	0000002b _strrchr
> 00000000       F *UND*	00000000 __syscall
> 0000083c  w    F .text	00000033 dlerror
> 00000000       F *UND*	0000002b printf
> 00001b80 g     O .bss	00000004 __mainprog_obj
> 00001b88 g     O .bss	00000004 p
> 00000934 g     F .text	00000041 f3
> 
> mainmips/libf3.so:     file format elf32-littlemips
> 
> SYMBOL TABLE:
> 5ffe10f0       F *UND*	00000034 __syscall
> 5ffe0e20  w    F *ABS*	00000000 dlerror
> 5ffe1100       F *UND*	00000068 printf
> 60021314 g     O *ABS*	00000004 p
> 5ffe1040 g     F *ABS*	000000ac f3
> 
> The difference is that the mips symbol table has all symbols as *ABS*,
> whether they are text (functions) or data.  
> 
> When the library is loaded, text and data are relocated separately
> since they are two separate mmap regions.  So the relocation bias is
> different for the two.  The i386 case works because the symbols are
> correctly marked as to which region they belong to (text, data, bss).
> But the mips case doesn't have that, so all symbol relocation is done
> as if the symbols were text.  The data and bss offsets are fine as
> file offsets, but because the parts are mapped separately they are NOT
> valid as memory address offsets.
> 
> I'm wondering what the right way to fix this is.  Two ways come to
> mind:
> 
> 1. Fix ld so it puts the right section designations on the symbols,
>    just as in the i386 case.
> 
> 2. Hack gdb so it looks at the section headers in the shared library
>    file, to extract the start and length of the three regions.  Use
>    that to identify the *ABS* symbols (i.e., p is bss since it's
>    within the vaddr range of the bss section in the section headers),
>    and then figure the correct relocation from that.
> 
> I can do (2), and that has the advantage of working with existing
> binaries, but it seems ugly.  (1) sounds right.  There are two issues
> there, though.  One is that I don't know ld.  The other is that I'm
> guessing there must be SOME reason why *ABS* is used for the mips
> case, though I can't imagine any reason.

(1) sounds right to me too, though I share your concern that there may
be some reason that ABS must be used the way it is for mips.  I think
you ought to ask about this on the binutils list...

If you have to do (2), I strongly encourage you to create a new solib
backend for it.

Kevin