This is the mail archive of the
mailing list for the GDB project.
Re: relocation of shared libs not based at 0
- From: Paul Koning <pkoning at equallogic dot com>
- To: kevinb at redhat dot com
- Cc: kewarken at qnx dot com, gdb at sources dot redhat dot com, peterv at qnx dot com, cburgess at qnx dot com
- Date: Mon, 10 Feb 2003 17:45:06 -0500
- 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><1030205191053.ZM3334@localhost.localdomain>
>>>>> "Kevin" == Kevin Buettner <email@example.com> writes:
Kevin> 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....
>> 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
>> 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.
Kevin> (1) sounds right to me too, though I share your concern that
Kevin> there may be some reason that ABS must be used the way it is
Kevin> for mips. I think you ought to ask about this on the binutils
Kevin> If you have to do (2), I strongly encourage you to create a
Kevin> new solib backend for it.
I was looking at solib-svr4.c and found this interesting comment (in
/* It is necessary to relocate the objfile. The amount to
relocate by is simply the address at which we are stopped
minus the starting address from the executable.
We relocate all of the sections by the same amount. This
behavior is mandated by recent editions of the System V ABI.
According to the System V Application Binary Interface,
Edition 4.1, page 5-5:
... Though the system chooses virtual addresses for
individual processes, it maintains the segments' relative
positions. Because position-independent code uses relative
addressesing between segments, the difference between
virtual addresses in memory must match the difference
between virtual addresses in the file. The difference
between the virtual address of any segment in memory and
the corresponding virtual address in the file is thus a
single constant value for any one executable or shared
object in a given process. This difference is the base
address. One use of the base address is to relocate the
memory image of the program during dynamic linking.
The same language also appears in Edition 4.0 of the System V
ABI and is left unspecified in some of the earlier editions. */
So if I read that right, it sounds like the NetBSD practice of doing
separate mappings for the text, data, and bss sections (rather than
leaving them at the same relative offset they were in the library
file) violates the SVR4 spec.
Very interesting. I'm not sure what to make of this. It doesn't feel
like a bug; the NetBSD behavior certainly makes sense.
That suggests at least two other approaches:
3. Change NetBSD ld.elf_so to do what the ABI spec requires, which
means just one mapped region rather than three.
4. Change the linker so ld.elf_so can still use three regions, i.e.,
align the start of each region on a page boundary.
Yikes. Now what? I may end up just doing (2) for the sake of
in-house expedience, and hope someone more skilled in the art will
tackle the "right" solution.