public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "corinna at vinschen dot de" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable
Date: Mon, 13 Feb 2023 16:17:54 +0000 [thread overview]
Message-ID: <bug-18027-4717-bEl4LsV9kj@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-18027-4717@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18027
--- Comment #5 from Corinna Vinschen <corinna at vinschen dot de> ---
(In reply to Simon Marchi from comment #4)
> Can you post a session of this working? I don't understand how the debug
> info being separate changes this behavior. I'd be interested in seeing the
> output of "info breakpoint", to see how GDB placed the same breakpoints as
> you placed in other sessions.
Ok, so here's the same DLL, stripped at package creation time,
installed into /usr/bin, and rebased to 0x300000000:
------------------------------------------------------------------------------
$ objdump -h /usr/bin/cygmagic-1.dll
/bin/cygmagic-1.dll: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0001d5e8 0000000300001000 0000000300001000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 000001c0 000000030001f000 000000030001f000 0001da00 2**4
CONTENTS, ALLOC, LOAD, DATA
2 .rdata 000065f8 0000000300020000 0000000300020000 0001dc00 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .buildid 00000035 0000000300027000 0000000300027000 00024200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .pdata 000009e4 0000000300028000 0000000300028000 00024400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .xdata 00000ab4 0000000300029000 0000000300029000 00024e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .bss 000004d0 000000030002a000 000000030002a000 00000000 2**4
ALLOC
7 .edata 00000c75 000000030002b000 000000030002b000 00025a00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .idata 00001214 000000030002c000 000000030002c000 00026800 2**2
CONTENTS, ALLOC, LOAD, DATA
9 .reloc 000001f4 000000030002e000 000000030002e000 00027c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .gnu_debuglink 00000018 000000030002f000 000000030002f000 00027e00 2**2
CONTENTS, READONLY, DEBUGGING
------------------------------------------------------------------------------
Debuginfo split off at package creation time with default addresses
for this DLL intact:
------------------------------------------------------------------------------
$ $ objdump -h /usr/lib/debug/usr/bin/cygmagic-1.dll.dbg
/usr/lib/debug/usr/bin/cygmagic-1.dll.dbg: file format pei-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0001d5e8 00000004d9221000 00000004d9221000 00000000 2**4
ALLOC, LOAD, READONLY, CODE, DATA
1 .data 000001c0 00000004d923f000 00000004d923f000 00000000 2**4
ALLOC, LOAD, DATA
2 .rdata 000065f8 00000004d9240000 00000004d9240000 00000000 2**4
ALLOC, LOAD, READONLY, DATA
3 .buildid 00000035 00000004d9247000 00000004d9247000 00000600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .pdata 000009e4 00000004d9248000 00000004d9248000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
5 .xdata 00000ab4 00000004d9249000 00000004d9249000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
6 .bss 000004d0 00000004d924a000 00000004d924a000 00000000 2**4
ALLOC
7 .edata 00000c75 00000004d924b000 00000004d924b000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
8 .idata 00001214 00000004d924c000 00000004d924c000 00000000 2**2
ALLOC, LOAD, DATA
9 .reloc 000001f4 00000004d924e000 00000004d924e000 00000000 2**2
ALLOC, LOAD, READONLY, DATA
10 .debug_aranges 000005d0 00000004d924f000 00000004d924f000 00000800 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_info 0004186a 00000004d9250000 00000004d9250000 00000e00 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 00005acf 00000004d9292000 00000004d9292000 00042800 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 000150e4 00000004d9298000 00000004d9298000 00048400 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 000056a0 00000004d92ae000 00000004d92ae000 0005d600 2**0
CONTENTS, READONLY, DEBUGGING
15 .debug_str 0000055b 00000004d92b4000 00000004d92b4000 00062e00 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_line_str 00003107 00000004d92b5000 00000004d92b5000 00063400
2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_loclists 000211c5 00000004d92b9000 00000004d92b9000 00066600
2**0
CONTENTS, READONLY, DEBUGGING
18 .debug_rnglists 000025a9 00000004d92db000 00000004d92db000 00087800
2**0
CONTENTS, READONLY, DEBUGGING
19 .gnu_debuglink 0000000c 00000004d92de000 00000004d92de000 00089e00 2**2
CONTENTS, READONLY, DEBUGGING
------------------------------------------------------------------------------
Now let's debug it:
------------------------------------------------------------------------------
$ gdb /usr/bin/file
GNU gdb (GDB) (Cygwin 12.1-1) 12.1
[...]
Reading symbols from /usr/bin/file...
Reading symbols from /usr/lib/debug//usr/bin/file.exe.dbg...
(gdb) sta /usr/bin/file.exe
Temporary breakpoint 1 at 0x100402400: file
/usr/src/debug/file-5.44-1/src/file.c, line 192.
Starting program: /usr/bin/file /usr/bin/file.exe
[...]
Thread 1 "file" hit Temporary breakpoint 1, main (argc=2, argv=0x7ffffcc40) at
/usr/src/debug/file-5.44-1/src/file.c:192
192 {
(gdb) br file_fsmagic
Breakpoint 2 at 0x3000173b0: file /usr/src/debug/file-5.44-1/src/fsmagic.c,
line 107.
(gdb) c
Continuing.
[New Thread 2960.0x2164]
[New Thread 2960.0xbe8]
Thread 1 "file" hit Breakpoint 2, file_fsmagic (ms=ms@entry=0xa00001710,
fn=fn@entry=0x7ffffcc79 "/usr/bin/file.exe", sb=sb@entry=0x7ffffc980) at
/usr/src/debug/file-5.44-1/src/fsmagic.c:107
107 {
(gdb) info br
info br
Num Type Disp Enb Address What
2 breakpoint keep y 0x00000003000173b0 in file_fsmagic
at
/usr/src/debug/file-5.44-1/src/fsmagic.c:107
breakpoint already hit 1 time
(gdb)
------------------------------------------------------------------------------
As an extra datapoint, if ASLR is active for this DLL, it can be moved
to any arbitrary free address by the OS, without GDB choking on that
load address. For instance:
------------------------------------------------------------------------------
(gdb) br file_fsmagic
Breakpoint 2 at 0x7fff658e73b0: file /usr/src/debug/file-5.44-1/src/fsmagic.c,
line 107.
(gdb) c
Continuing.
[New Thread 5988.0xe40]
[New Thread 5988.0xe80]
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) info br
Num Type Disp Enb Address What
2 breakpoint keep y 0x00007fff658e73b0 in file_fsmagic
at
/usr/src/debug/file-5.44-1/src/fsmagic.c:107
breakpoint already hit 1 time
------------------------------------------------------------------------------
For the unstripped DLL, this is also true... as long as it hasn't been
rebased! If the unstripped DLL got rebased, the same problem occurs
for the ASLR'ed address:
------------------------------------------------------------------------------
(gdb) br file_fsmagic
Breakpoint 2 at 0x7fff658e73c3 (2 locations)
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x80013eb073b0
Command aborted.
(gdb)
------------------------------------------------------------------------------
Does that help?
I'm pretty sure the problem is that the dwarf2 debug info contains
absolute addresses which don't match the load address of the DLL after
rebase.
Being loaded to other addresses (ASLR) is taken into account, GDB
computes the offset between load address in the file header and actual
load address in VM and utilizes it throughout.
However, as soon as the DLL gets rebased, the addresses in the debug
info and the load address in the DLL header are "off", so the offset
computation doesn't work anymore.
Just guessing here, of course.
Thanks,
Corinna
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2023-02-13 16:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 5:36 [Bug win32/18027] New: " corinna at vinschen dot de
2015-02-26 9:39 ` [Bug win32/18027] " asmwarrior at gmail dot com
2023-02-11 17:48 ` tromey at sourceware dot org
2023-02-12 12:20 ` ssbssa at sourceware dot org
2023-02-13 10:31 ` corinna at vinschen dot de
2023-02-13 10:36 ` corinna at vinschen dot de
2023-02-13 14:01 ` simark at simark dot ca
2023-02-13 16:17 ` corinna at vinschen dot de [this message]
2023-02-13 17:13 ` simark at simark dot ca
2023-02-13 17:24 ` ssbssa at sourceware dot org
2023-02-13 19:23 ` tromey at sourceware dot org
2023-02-13 19:46 ` ssbssa at sourceware dot org
2023-02-13 19:48 ` corinna at vinschen dot de
2023-02-13 22:08 ` tromey at sourceware dot org
2023-02-15 10:22 ` corinna at vinschen dot de
2023-02-17 2:15 ` tromey at sourceware dot org
2023-02-28 14:43 ` tromey at sourceware dot org
2023-02-28 15:20 ` corinna at vinschen dot de
2023-02-28 15:22 ` corinna at vinschen dot de
2023-03-24 17:31 ` tromey at sourceware dot org
2023-03-24 19:00 ` corinna at vinschen dot de
2023-03-27 9:19 ` nickc at redhat dot com
2023-03-28 8:58 ` corinna at vinschen dot de
2023-03-28 14:01 ` nickc at redhat dot com
2023-03-28 18:10 ` corinna at vinschen dot de
2023-03-29 12:46 ` tromey at sourceware dot org
2023-03-30 9:23 ` corinna at vinschen dot de
2023-03-30 9:24 ` corinna at vinschen dot de
2023-04-21 16:38 ` tromey at sourceware dot org
2023-04-21 16:54 ` tromey at sourceware dot org
2023-04-21 17:11 ` tromey at sourceware dot org
2023-04-21 19:48 ` corinna at vinschen dot de
2023-04-24 15:54 ` tromey at sourceware dot org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-18027-4717-bEl4LsV9kj@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=gdb-prs@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).