public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/111409] New: Invalid .debug_macro.dwo macro information for split DWARF
@ 2023-09-13 21:29 osandov at osandov dot com
  2023-09-14  6:51 ` [Bug debug/111409] " osandov at osandov dot com
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: osandov at osandov dot com @ 2023-09-13 21:29 UTC (permalink / raw)
  To: gcc-bugs

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.)

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-05-21 15:05 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-13 21:29 [Bug debug/111409] New: Invalid .debug_macro.dwo macro information for split DWARF osandov at osandov dot com
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

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).