This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: relocation of shared libs not based at 0
- From: Peter van der Veen <peterv at qnx dot com>
- To: 'Kevin Buettner' <kevinb at redhat dot com>, 'Paul Koning' <pkoning at equallogic dot com>
- Cc: Kris Warkentin <KEWarken at qnx dot com>, "'gdb at sources dot redhat dot com'" <gdb at sources dot redhat dot com>, Peter van der Veen <peterv at qnx dot com>, Colin Burgess <cburgess at qnx dot com>
- Date: Wed, 12 Feb 2003 13:37:46 -0500
- Subject: RE: relocation of shared libs not based at 0
> From: Kevin Buettner [mailto:kevinb@redhat.com]
>
> On Feb 10, 5:45pm, Paul Koning wrote:
>
> > >> 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.
> >
> > 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> list...
> >
> > 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
> > svr4_relocate_main_executable):
> >
> > /* 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.
>
> Yes, upon rereading that comment, I agree with you.
>
> If you haven't already done so, you may want to take a look at the ABI
> yourself to make sure that the comment quotes the ABI correctly and
> to understand the context of the quote. I wrote that comment, and
> I believe it to be accurate with sufficient context, but it doesn't
> hurt for someone else to double check.
>
> You should also take a look at the processor specific supplement. I
> don't think that the processor supplement will override the text
> quoted above from the generic part of the specification, but this
> possibility should be checked before declaring the NetBSD
> implementation wrong.
>
> > 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.
>
> If NetBSD wants to comply with the System V ABI (and if I've
> interpreted the text of the ABI correctly), then the dynamic linker
> needs fixing.
I'm not sure if this is what you are referring to, but here is what I have
observed. The System V ABI makes statements about base address, and relative
to that document base address is consistent. But the base address in the
l_addr field in link.h is not the same base address that the system V abi is
talking about. I think problems started when someone saw these both referred
to as "base address" and assumed they both where the same value. l_addr is
the address of the library at load time, but not the same value as the base
address in the ABI. I would think your comment that the NETBSD behaviour
does not feel like a bug is correct. I think the linux ld.so may treat both
base addresses as being the same thing, but I am not sure.
>
> I can understand wanting to do (2) for expediency's sake. If you do
> so, please create a new solib backend. Basically, this will consist
> of making a copy of solib-svr4.c and hacking on it 'til it works as
> desired. (Some small configury changes will also be needed.)