Re: relocation of shared libs not based at 0

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Kris" == Kris Warkentin <kewarken@qnx.com> writes:

 Kris> I recently came across a problem debugging a core file with
 Kris> some of our older shared libs.  Info shared showed the
 Kris> relocations of the shared libs to be mangled (offset to
 Kris> 0x60... range rather than 0xb0... range).  We had recently
 Kris> changed our tools to always set the vaddr of shared libs to be
 Kris> zero because of this but I was speaking to one of our
 Kris> architects and he says that this shouldn't be.

 Kris> One of the future optimizations we're looking at is
 Kris> pre-relocating shared libs so that they can be executed in
 Kris> place (on flash for instance) and the fact that the SysV stuff
 Kris> seems to assume that everything is based at zero is not
 Kris> particularily compatable with that.  I've attached an ugly
 Kris> patch that shows a fix.  This is for illustration only since
 Kris> solib.c is the wrong place to put this but it makes it clear
 Kris> what the issue is.

 Kris> Can anyone with more knowledge than I enlighten me as to a)
 Kris> whether it is proper to allow shared objects to be non
 Kris> zero-based and b) a better way to do this.  I looked at putting
 Kris> it in solib-svr4.c but I don't have access to the bfd in there,
 Kris> at least in svr4_relocate_section_addresses().

I ran into the same problem when trying to get gdb to deal correctly
with shared libs on NetBSD/MIPS.  The following patch is my attempt at
dealing with it.  I haven't tried to turn this into a patch submission
because I don't trust my gdb hacking skills yet.  Also, I was
concentrating on "making it work" (for NetBSD/MIPS, the platform we
needed to get right) rather than "doing the right thing" for gdb
generally.  BTW, this is a patch against a snapshot of 5.3 taken a few
months ago.

       paul

diff -u -r1.1.1.2 -r1.2
--- console_gdb/gdb/solib-svr4.c	2002/10/03 19:50:00	1.1.1.2
+++ console_gdb/gdb/solib-svr4.c	2002/10/07 20:45:23	1.2
@@ -1259,8 +1259,24 @@
 svr4_relocate_section_addresses (struct so_list *so,
                                  struct section_table *sec)
 {
+#if 0 /* wrong: LM_ADDR is the assigned address, not the offset */
   sec->addr    = svr4_truncate_ptr (sec->addr    + LM_ADDR (so));
   sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so));
+#else
+  /* The addresses are formed as follows:
+     LM_ADDR is the target address where the shared library file
+     is mapped.
+     So the actual section start address is LM_ADDR plus the section 
+     offset within the shared library file.  The end address is that
+     plus the section length.  Note that we pay no attention to the
+     section start address as recorded in the library header.
+  */
+  sec->endaddr = svr4_truncate_ptr (sec->endaddr - sec->addr +
+				    sec->the_bfd_section->filepos +
+				    LM_ADDR (so));
+  sec->addr    = svr4_truncate_ptr (sec->the_bfd_section->filepos +
+				    LM_ADDR (so));
+#endif
 }