This is the mail archive of the
mailing list for the GDB project.
Re: relocation of shared libs not based at 0
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Paul Koning <pkoning at equallogic dot com>, kewarken at qnx dot com
- Cc: kevinb at redhat dot com, gdb at sources dot redhat dot com, peterv at qnx dot com, cburgess at qnx dot com
- Date: Wed, 5 Feb 2003 12:10:54 -0700
- Subject: Re: relocation of shared libs not based at 0
- References: <032c01c2a60a$2368a6e0$0202040a@catdog> <1021218002802.ZM4459@localhost.localdomain> <email@example.com> <08ab01c2b760$2e6612a0$0202040a@catdog> <firstname.lastname@example.org.HOWL>
On Feb 5, 2:40pm, Paul Koning wrote:
> I'm resurrecting this thread to bring up a problem that's closely
> 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
> 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.