This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


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

Re: RFC: ELF prelinker - 0.1.1


On Thu, Jul 05, 2001 at 09:53:00AM +0100, James Cownie wrote:
> Jakub, you wrote :- 
> 
> > Still unfinished in this area is relocating of Dwarf/Dwarf-2 (but
> > Stabs are already done) - the debugging formats are tricky because
> > they don't have corresponding .rel* sections in shared libraries, so
> > one has to understand the format and see what values need to be
> > adjusted and what not.
> 
> But I don't believe that you should be relocating either Stabs or
> DWARF. 

I have to. Debugger relocates them too, but debugger relocates them by
adding link_map->l_addr, which is load address, not base address.
Load address is the difference between actual virtual addresses in library
and virtual addresses stored in the library.
Program headers of typical non-prelinked library look like:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x00000034 0x00000034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0019a0 0x000019a0 0x000019a0 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x00000000 0x00000000 0x019b3 0x019b3 R E 0x1000
  LOAD           0x0019b4 0x000029b4 0x000029b4 0x001a0 0x001b8 RW  0x1000
  DYNAMIC        0x001a74 0x00002a74 0x00002a74 0x000e0 0x000e0 RW  0x4
  NOTE           0x0000f4 0x000000f4 0x000000f4 0x00020 0x00020 R   0x4

while for prelinked look like:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x41ec8034 0x41ec8034 0x000c0 0x000c0 R E 0x4
  INTERP         0x0019a0 0x41ec99a0 0x41ec99a0 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x41ec8000 0x41ec8000 0x019b3 0x019b3 R E 0x1000
  LOAD           0x0019b4 0x41eca9b4 0x41eca9b4 0x001a0 0x001b8 RW  0x1000
  DYNAMIC        0x001a74 0x41ecaa74 0x41ecaa74 0x000e0 0x000e0 RW  0x4
  NOTE           0x0000f4 0x41ec80f4 0x41ec80f4 0x00020 0x00020 R   0x4

If Stabs/DWARF was not adjusted, then it would use very low addresses (above
in range 0 - 0x2b6c), but e.g. Symtab in the prelinked library has to use
the real virtual addresses, e.g.:
    44: 41ec9374   108 FUNC    GLOBAL DEFAULT   12 login_tty@@GLIBC_2.0
    45: 41ec8ef4  1136 FUNC    GLOBAL DEFAULT   12 login@@GLIBC_2.0
When gdb loads these stabs, it would relocate them by adding l_addr (unless
something else occupied 0x41ec80000-0x41ecab6c virtual slot first, l_addr
will be 0), then you're not referring to proper addresses.

FYI I have tested my stabs code, and it is possible to debug such prelinked
libraries with unmodified gdb, unlike prior to adding the stabs relocation
code yesterday.

> For things in dynamic libraries the stabs/dwarf addresses should be
> those of the unrelocated library (i.e. offsets from the address at
> whic hthe library is loaded). It's up to the debugger to add in the
> appropriate base address when it knows where the library actually got
> loaded in a specific process.
> 
> Consider that in the normal course of events the dynamic linker cannot
> possibly relocate stabs/dwarf because these sections are not loaded in
> to store.
> 
> I believe that if you relocate the stabs/dwarf then things will fail
> because debuggers will _also_ relocate them (using the information
> they get from the dynamic linker's list of "struct link_map" items),
> and the result will be that the base offset of the dynamic library
> will be added in _twice_.

	Jakub


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