From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4F3813858426; Mon, 13 Feb 2023 10:31:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4F3813858426 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676284301; bh=ppZpCKO9Pqkw3rDPO6GmKHvz2HmKbzrVkgQAv7FJmww=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RaD0FOmZYcDvmbeuHoAYY3TMFoRi+AEJV8bDecUaIXCY9EAtKPuDGblhQU8w5GGvF R8dTwJwZZOZXWpWeSHztu3i6AKlp3NTtVOqZAWsImKocxbPF7fz3yjsSujICLJnFFw bZPlxFaduogYndGwaLRGWFbzzdliev7zcLK/xPUc= From: "corinna at vinschen dot de" To: gdb-prs@sourceware.org Subject: [Bug win32/18027] dwarf2 debug info after rebasing DLLs unusable Date: Mon, 13 Feb 2023 10:31:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: win32 X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: corinna at vinschen dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D18027 --- Comment #2 from Corinna Vinschen --- 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=20= =20 sections following the header must start at the next 4K-aligned address without leaving holes, even NOLOAD sections!=20=20 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) =3D=3D 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 A= lgn 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= =20 2**0 CONTENTS, READONLY, DEBUGGING 17 .debug_loclists 000211c5 00000004d92b9000 00000004d92b9000 0008e200= =20 2**0 CONTENTS, READONLY, DEBUGGING 18 .debug_rnglists 000025a9 00000004d92db000 00000004d92db000 000af400= =20 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=3Dms@entry=3D0xa00001770, fn=3Dfn@entry=3D0x7ffffcc7e "file.exe", sb=3Dsb@entry=3D0x7ffffc950) 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 address= es 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 A= lgn 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= =20 2**0 CONTENTS, READONLY, DEBUGGING 17 .debug_loclists 000211c5 0000000300099000 0000000300099000 0008e200= =20 2**0 CONTENTS, READONLY, DEBUGGING 18 .debug_rnglists 000025a9 00000003000bb000 00000003000bb000 000af400= =20 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 --=20 You are receiving this mail because: You are on the CC list for the bug.=