[Bug binutils/18025] New: dwarf2 debug info after rebasing DLLs unusable

[corinna at vinschen dot de]

https://sourceware.org/bugzilla/show_bug.cgi?id=18025

            Bug ID: 18025
           Summary: dwarf2 debug info after rebasing DLLs unusable
           Product: binutils
           Version: 2.26 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: corinna at vinschen dot de
            Target: cygwin, i686 and x86_64

Hi,

we're encountering a problem evaluating Dwarf2 debug info in DLLs after
rebasing the DLL.  Rebasing, that is, moving the image base address of a
DLL and adjusting the relocation information, is an essential part of
DLL handling in the Cygwin distro, required for smooth operation of
the fork emulation.

Consider a DLL built with debug info, unstripped.  As an example, I'm
using the latest file-5.22-1 package which comes with a DLL called
cygmagic-1.dll.  The output of objdump -h on the built DLL looks like this:

$ objdump -h cygmagic-1.dll.

cygmagic-1.dll:     file format pei-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00013618  00000004d9221000  00000004d9221000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         00000068  00000004d9235000  00000004d9235000  00013e00  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        00005258  00000004d9236000  00000004d9236000  00014000  2**6
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 [...]
 10 .debug_aranges 00000510  00000004d9243000  00000004d9243000  0001c400  2**4
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   0002b4ab  00000004d9244000  00000004d9244000  0001ca00  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 00003d2b  00000004d9270000  00000004d9270000  00048000  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   00006046  00000004d9274000  00000004d9274000  0004be00  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  00002b68  00000004d927b000  00000004d927b000  00052000  2**3
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    00000302  00000004d927e000  00000004d927e000  00054c00  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_loc    000259a2  00000004d927f000  00000004d927f000  00055000  2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_ranges 00003230  00000004d92a5000  00000004d92a5000  0007aa00  2**0
                  CONTENTS, READONLY, DEBUGGING

Notice the VMA addresses.  The DLL is based at 0x4d9220000.  This DLL
works and evaluating the debug info works nicely.  This is the  `nm -l'
output before rebasing:

  $ nm -l cygmagic-1.dll | grep usr/src/debug
  [...]
  00000004d922bd80 T file_fmttime /usr/src/debug/file-5.22-1/src/print.c:232
  00000004d922c520 T file_fsmagic /usr/src/debug/file-5.22-1/src/fsmagic.c:104
  00000004d922d3f0 T file_getbuffer      
/usr/src/debug/file-5.22-1/src/funcs.c
:321
  00000004d922b120 T file_is_tar  /usr/src/debug/file-5.22-1/src/is_tar.c:64
  00000004d922a1d0 T file_looks_utf8     
/usr/src/debug/file-5.22-1/src/encodin
g.c:295
  [...]

So it shows the sources and line numbers for the symbols as expected:

  $ nm -l cygmagic-1.dll | grep usr/src/debug | wc -l
  198

And here's what happens after rebase to some arbitrary address:

  $ rebase -b 0x300000000 cygmagic-1.dll
  $ nm -l cygmagic-1.dll | grep usr/src/debug | wc -l
  0

nm lost all connection between the symbols and their sources.

Checking with GDB: In GDB you can set a breakpoint on this function and
it's loaded to the same address.  When breaking, GDB shows the function,
its arguments, and the source line:
  Breakpoint 1, file_fsmagic (address@hidden,
      address@hidden "./file", address@hidden)
      at /usr/src/debug/file-5.22-1/src/fsmagic.c:104
  104     {

After rebasing to, e.g., 0x300000000 as above, it looks like this:

  $ rebase -b 0x300000000 cygmagic-1.dll
  $ nm cygmagic-1.dll | grep file_fsmagic
  000000030000c520 T file_fsmagic

  (gdb) r ./file
  Starting program: /usr/bin/file ./file
  [New Thread 2696.0xecc]
  Warning:
  Cannot insert breakpoint 1.
  Cannot access memory at address 0x4d922c520

So, apparently the debug info uses absolute addresses, rather than
image base relative or section relative addresses.  After rebasing,
the info points to invalid addresses.

Shouldn't binutils be aware of the effect of rebasing, and make sure
that the existing debug info is correctly evaluated even after rebase?

Even better, shouldn't the dwarf2 debug info be defined image base
relative rather than using absolute addressing, to make sure it
still contains valid information even after rebasing a DLL?  At least
on PE/COFF targets?


Thanks,
Corinna

-- 
You are receiving this mail because:
You are on the CC list for the bug.