[Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable

["corinna at vinschen dot de" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #2 from Corinna Vinschen <corinna at vinschen dot de> ---
Yes, this is still an issue, and, as I wrote originally, it's still
restricted to DLLs with integrated dwarf2 debug sections.

If the debug sections are only present in an external debuginfo file,
like, in the example of the `file' package I used for this case,
/usr/lib/debug/usr/bin/cygmagic-1.dll.dbg, rebasing the DLL is no
problem and resolving debug symbols in GDB continues to work as desired.

So, what happens when rebasing the DLL?

Lets start with how PE/COFF sections are organized.  Windows stores a
load address in the file header.  The header has a size of 4K. all other  
sections following the header must start at the next 4K-aligned address
without leaving holes, even NOLOAD sections!  

When rebase runs, it changes the load address in the PE/COFF header, and
it changes all start addresses of all sections according to the above
rule.  So when rebasing a DLL to, say, 0x30000000, the load address in
the header will be 0x300000000, the start address of the next section
0x300001000. If the section has a size of 10K, the next section will
start at 0x300001000 + 10K 4K-aligened) == 0x300004000, and so on.

Let's make an example with the most recent file package anew:

The current cygmagic-1.dll, freshly built, starts at load address
0x4d9220000.

So the objdump output of the unstripped 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         0001d5e8  00000004d9221000  00000004d9221000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         000001c0  00000004d923f000  00000004d923f000  0001dc00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        000065d8  00000004d9240000  00000004d9240000  0001de00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  00000004d9247000  00000004d9247000  00024400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .pdata        000009e4  00000004d9248000  00000004d9248000  00024600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .xdata        00000ab4  00000004d9249000  00000004d9249000  00025000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss          000004d0  00000004d924a000  00000004d924a000  00000000  2**4
                  ALLOC
  7 .edata        00000c75  00000004d924b000  00000004d924b000  00025c00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .idata        00001214  00000004d924c000  00000004d924c000  00026a00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reloc        000001f4  00000004d924e000  00000004d924e000  00027e00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .debug_aranges 000005d0  00000004d924f000  00000004d924f000  00028000  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   0004186a  00000004d9250000  00000004d9250000  00028600  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 00005acf  00000004d9292000  00000004d9292000  0006a000  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   000150e4  00000004d9298000  00000004d9298000  0006fc00  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  000056a0  00000004d92ae000  00000004d92ae000  00084e00  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    0000055b  00000004d92b4000  00000004d92b4000  0008a600  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_line_str 00003431  00000004d92b5000  00000004d92b5000  0008ac00 
2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_loclists 000211c5  00000004d92b9000  00000004d92b9000  0008e200 
2**0
                  CONTENTS, READONLY, DEBUGGING
 18 .debug_rnglists 000025a9  00000004d92db000  00000004d92db000  000af400 
2**0
                  CONTENTS, READONLY, DEBUGGING
-------------------------------------------------------------------------------

If I use this DLL for debugging I get the expected result:

-------------------------------------------------------------------------------
$ gdb ./file.exe
GNU gdb (GDB) (Cygwin 12.1-1) 12.1
[...]
(gdb) start file.exe
Temporary breakpoint 1 at 0x100402400: file
/usr/src/debug/file-5.44-1/src/file.c, line 192.
Starting program:
/home/corinna/tmp/file/file-5.44-1.x86_64/build/src/.libs/file.exe file.exe
[...]
(gdb) (gdb) br file_fsmagic
Breakpoint 2 at 0x4d92373b0: file /usr/src/debug/file-5.44-1/src/fsmagic.c,
line 107.
(gdb) c
Continuing.

Thread 1 "file" hit Breakpoint 2, file_fsmagic (ms=ms@entry=0xa00001770,
fn=fn@entry=0x7ffffcc7e "file.exe", sb=sb@entry=0x7ffffc950) at
/usr/src/debug/file-5.44-1/src/fsmagic.c:107
107     {
(gdb)
-------------------------------------------------------------------------------

Now I rebase the DLL to a new load address 0x300000000.  As I wrote above,
this will change the load address in the header as well as the load addresses
of all sections accordingly:

-------------------------------------------------------------------------------
$ rebase -b 0x300000000 cygmagic-1.dll
$ objdump -h cygmagic-1.dll

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

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         0001d5e8  0000000300001000  0000000300001000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         000001c0  000000030001f000  000000030001f000  0001dc00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        000065d8  0000000300020000  0000000300020000  0001de00  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .buildid      00000035  0000000300027000  0000000300027000  00024400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .pdata        000009e4  0000000300028000  0000000300028000  00024600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .xdata        00000ab4  0000000300029000  0000000300029000  00025000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss          000004d0  000000030002a000  000000030002a000  00000000  2**4
                  ALLOC
  7 .edata        00000c75  000000030002b000  000000030002b000  00025c00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .idata        00001214  000000030002c000  000000030002c000  00026a00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reloc        000001f4  000000030002e000  000000030002e000  00027e00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 10 .debug_aranges 000005d0  000000030002f000  000000030002f000  00028000  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_info   0004186a  0000000300030000  0000000300030000  00028600  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_abbrev 00005acf  0000000300072000  0000000300072000  0006a000  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_line   000150e4  0000000300078000  0000000300078000  0006fc00  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_frame  000056a0  000000030008e000  000000030008e000  00084e00  2**0
                  CONTENTS, READONLY, DEBUGGING
 15 .debug_str    0000055b  0000000300094000  0000000300094000  0008a600  2**0
                  CONTENTS, READONLY, DEBUGGING
 16 .debug_line_str 00003431  0000000300095000  0000000300095000  0008ac00 
2**0
                  CONTENTS, READONLY, DEBUGGING
 17 .debug_loclists 000211c5  0000000300099000  0000000300099000  0008e200 
2**0
                  CONTENTS, READONLY, DEBUGGING
 18 .debug_rnglists 000025a9  00000003000bb000  00000003000bb000  000af400 
2**0
                  CONTENTS, READONLY, DEBUGGING
-------------------------------------------------------------------------------

Now I try to debug this DLL:

-------------------------------------------------------------------------------
$ gdb ./file.exe
GNU gdb (GDB) (Cygwin 12.1-1) 12.1
[...]
Temporary breakpoint 1 at 0x100402400: file
/usr/src/debug/file-5.44-1/src/file.c, line 192.
Starting program:
/home/corinna/tmp/file/file-5.44-1.x86_64/build/src/.libs/file.exe file.exe
[...]
(gdb) br file_fsmagic
Breakpoint 2 at 0x3000173c3 (2 locations)
-------------------------------------------------------------------------------

Compare that with setting the breakpoint while debugging the un-rebased DLL.
Next I try to continue:

-------------------------------------------------------------------------------
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x4d92373b0

Command aborted.
(gdb)
-------------------------------------------------------------------------------

Observe the address GDB is trying to set a breakpoint to!  It's still an
address which only makes sense if the DLL hasn't been rebased.  The
address 0x4d92373b0 in the non-rebased DLL would actually be equivalent
to the address 0x3000173B0 in the rebased DLL.

Still, and just to be sure, if I create the DLL, split off the debuginfo
file and then rebase the DLL sans its debug sections, debuging works
nicely, albeit the debuginfo file continues to maintain the original
addresses.  I. e., the load address of the debuginfo file is still
0x4d9220000.


Thanks,
Corinna

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