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
- From: Paul Koning <pkoning at equallogic dot com>
- To: kewarken at qnx dot com
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 17 Dec 2002 15:31:53 -0500
- Subject: Re: relocation of shared libs not based at 0
- References: <032c01c2a60a$2368a6e0$0202040a@catdog>
>>>>> "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
}