Re: relocation of shared libs not based at 0

[Paul Koning <pkoning@equallogic.com>]

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.

Suggestions would be much appreciated.

      paul