Re: relocation of shared libs not based at 0

["Kris Warkentin" <kewarken@qnx.com>]

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