Re: relocation of shared libs not based at 0

[Kevin Buettner <kevinb at redhat dot 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 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