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: "Kris Warkentin" <kewarken at qnx dot com>
- To: "Paul Koning" <pkoning at equallogic dot com>
- Cc: <kevinb at redhat dot com>, <gdb at sources dot redhat dot com>, <peterv at qnx dot com>, <cburgess at qnx dot com>
- Date: Wed, 5 Feb 2003 14:08:07 -0500
- Subject: Re: relocation of shared libs not based at 0
- References: <032c01c2a60a$2368a6e0$0202040a@catdog><1021218002802.ZM4459@localhost.localdomain><15871.50596.942339.277490@pkoning.akdesign.com><08ab01c2b760$2e6612a0$0202040a@catdog> <15937.26809.680000.225947@gargle.gargle.HOWL>
I ran into the same problem: GDB was calculating that data in a shared lib
was off by a page (1k hex) which was very annoying. The original patch that
I had submitted doesn't seem to have this problem though so I went back and
re-inserted it.
The following is the code that I put into our qnx specific files. All I did
then was set
current_target_so_ops->relocate_section_addresses =
qnx_relocate_section_addresses to override the System V behaviour and all my
problems went away.
cheers,
Kris
#include "solist.h"
#include "solib-svr4.h"
/* struct lm_info, LM_ADDR and qnx_truncate_ptr are copied from
solib-svr4.c to support qnx_relocate_section_addresses which is different
from the svr4 version. */
struct lm_info
{
/* Pointer to copy of link map from inferior. The type is char *
rather than void *, so that we may use byte offsets to find the
various fields without the need for a cast. */
char *lm;
};
static CORE_ADDR
LM_ADDR (struct so_list *so)
{
struct link_map_offsets *lmo = SVR4_FETCH_LINK_MAP_OFFSETS ();
return (CORE_ADDR) extract_signed_integer (so->lm_info->lm +
lmo->l_addr_offset,
lmo->l_addr_size);
}
static CORE_ADDR
qnx_truncate_ptr (CORE_ADDR addr)
{
if (TARGET_PTR_BIT == sizeof (CORE_ADDR) * 8)
/* We don't need to truncate anything, and the bit twiddling below
will fail due to overflow problems. */
return addr;
else
return addr & (((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1);
}
#include "elf-bfd.h"
Elf_Internal_Phdr *find_load_phdr( bfd *abfd )
{
Elf32_Internal_Phdr *phdr;
unsigned int i;
phdr = elf_tdata (abfd)->phdr;
for (i = 0; i < elf_elfheader (abfd)->e_phnum; i++, phdr++) {
if (phdr->p_type == PT_LOAD && (phdr->p_flags & PF_X))
return phdr;
}
return NULL;
}
static void
qnx_relocate_section_addresses (struct so_list *so,
struct section_table *sec)
{
Elf32_Internal_Phdr *phdr = find_load_phdr(sec->bfd);
unsigned vaddr = phdr?phdr->p_vaddr:0;
sec->addr = qnx_truncate_ptr (sec->addr + LM_ADDR (so) - vaddr);
sec->endaddr = qnx_truncate_ptr (sec->endaddr + LM_ADDR (so) - vaddr);
}
----- Original Message -----
From: "Paul Koning" <pkoning@equallogic.com>
To: <kewarken@qnx.com>
Cc: <kevinb@redhat.com>; <gdb@sources.redhat.com>; <peterv@qnx.com>;
<cburgess@qnx.com>
Sent: Wednesday, February 05, 2003 2:40 PM
Subject: Re: relocation of shared libs not based at 0
> 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.
>
> After doing battle with various parts of gdb for quite some time, I
> finally realized what the issue is. What puzzled me is that it works
> just fine on netbsd-i386. That finally led me to the answer...
>
> The reason can be seen by looking at the symbol table. Here are
> (partial) objdump runs, first for i386, then for mips:
>
> mainx86/libf3.so: file format elf32-i386
>
> SYMBOL TABLE:
> 000006fc l F .text 0000002b _strrchr
> 00000000 F *UND* 00000000 __syscall
> 0000083c w F .text 00000033 dlerror
> 00000000 F *UND* 0000002b printf
> 00001b80 g O .bss 00000004 __mainprog_obj
> 00001b88 g O .bss 00000004 p
> 00000934 g F .text 00000041 f3
>
> mainmips/libf3.so: file format elf32-littlemips
>
> SYMBOL TABLE:
> 5ffe10f0 F *UND* 00000034 __syscall
> 5ffe0e20 w F *ABS* 00000000 dlerror
> 5ffe1100 F *UND* 00000068 printf
> 60021314 g O *ABS* 00000004 p
> 5ffe1040 g F *ABS* 000000ac f3
>
> The difference is that the mips symbol table has all symbols as *ABS*,
> whether they are text (functions) or data.
>
> 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.
>
> Suggestions would be much appreciated.
>
> paul
>
>