This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: relocation of shared libs not based at 0


>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

 Kevin> On Feb 5, 2:40pm, Paul Koning wrote:
 >> I'm resurrecting this thread to bring up a problem that's closely
 >> related.
 >> 
 >> 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
 >> mind:
 >> 
 >> 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
 >> 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.

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.

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]