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
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 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.)
Kevin