public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "osandov at osandov dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/111409] New: Invalid .debug_macro.dwo macro information for split DWARF Date: Wed, 13 Sep 2023 21:29:30 +0000 [thread overview] Message-ID: <bug-111409-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 Bug ID: 111409 Summary: Invalid .debug_macro.dwo macro information for split DWARF Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: osandov at osandov dot com Target Milestone: --- When using -g3 -gsplit-dwarf, the generated macro information has a couple of issues. I'm using the following trivial source file: $ cat test.c #define ZERO 0 int main(void) { return ZERO; } First, GCC emits DW_MACRO_import entries, but they always have an offset of 0: $ gcc -g3 -gsplit-dwarf test.c $ readelf --debug-dump=macro a-test.dwo | head -n 14 Contents of the .debug_macro.dwo section: Offset: 0x0 Version: 5 Offset size: 4 Offset into .debug_line: 0x0 DW_MACRO_import - offset : 0x0 DW_MACRO_start_file - lineno: 0 filenum: 1 DW_MACRO_start_file - lineno: 0 filenum: 2 DW_MACRO_import - offset : 0x0 DW_MACRO_end_file DW_MACRO_define_strx lineno : 1 macro : <no .debug_str_offsets section> DW_MACRO_end_file Second, each macro unit is in its own .debug_macro.dwo section: $ readelf -S -W a-test.dwo | grep -F .debug_macro [ 3] .debug_macro.dwo PROGBITS 0000000000000000 0000b2 00001e 00 E 0 0 1 [ 4] .debug_macro.dwo PROGBITS 0000000000000000 0000d0 00059e 00 0 0 1 [ 5] .debug_macro.dwo PROGBITS 0000000000000000 00066e 00001b 00 0 0 1 As far as I can tell, the DWARF specification doesn't allow this, and tools seem to only use either the first or last section (gdb only finds the first one, and dwp only copies the last one into the .dwp file). These seem to have the same underlying cause: when not using split DWARF, the linker deduplicates units and relocates the import offsets appropriately, but this is not possible with split DWARF. I imagine that the fix would be to not use imports for split DWARF and only generate one macro unit per .dwo file containing everything. (P.S., -g3 -gdwarf-4 -gstrict-dwarf -gsplit-dwarf generates a valid .debug_macinfo.dwo because it doesn't have a notion of imports.)
next reply other threads:[~2023-09-13 21:29 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-09-13 21:29 osandov at osandov dot com [this message] 2023-09-14 6:51 ` [Bug debug/111409] " osandov at osandov dot com 2023-09-20 6:03 ` cvs-commit at gcc dot gnu.org 2023-11-28 12:58 ` ro at gcc dot gnu.org 2024-02-27 0:57 ` osandov at osandov dot com 2024-05-21 15:04 ` vries at gcc dot gnu.org 2024-05-21 15:05 ` vries at gcc dot gnu.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-111409-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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).