RE: relocation of shared libs not based at 0

[Peter van der Veen <peterv@qnx.com>]

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