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] New: dwarf2 debug info after rebasing DLLs unusable Date: Thu, 26 Feb 2015 05:36:00 -0000 [thread overview] Message-ID: <bug-18027-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=18027 Bug ID: 18027 Summary: dwarf2 debug info after rebasing DLLs unusable Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: win32 Assignee: unassigned at sourceware dot org Reporter: corinna at vinschen dot de Hi, I reported the analog problem to binutils, see https://sourceware.org/bugzilla/show_bug.cgi?id=18025 but GDB is affected as well. 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(1) package which comes with a DLL called cygmagic-1.dll. The output of objdump -h 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. 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 (ms=ms@entry=0x6000394f0, fn=fn@entry=0x23cb75 "./file", sb=sb@entry=0x23c8f0) 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. However, when splitting off the debug info into an external *.dbg file and stripping the debug info from the original DLL, then debugging works fine even after rebsing the original DLL. So apparently GDB knows how to handle this situation, but it doesn't take it into account when the debug info is still present in the DLL itself. Can this be fixed, please? Ultimately I think the right thing to do would be to change the Dwarf2 debug info to 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. I mentioned this in the binutls bugreport https://sourceware.org/bugzilla/show_bug.cgi?id=18025 as well. Thanks, Corinna -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2015-02-25 15:54 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-26 5:36 corinna at vinschen dot de [this message] 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 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@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: linkBe 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).