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
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ 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] 5+ messages in thread

* [Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
  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 ` osandov at osandov dot com
  2023-09-20  6:03 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: osandov at osandov dot com @ 2023-09-14  6:51 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

--- Comment #1 from Omar Sandoval <osandov at osandov dot com> ---
Patch sent:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630242.html

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

* [Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
  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
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-09-20  6:03 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:80048aa13a6b55d2be485000840a4e1c8b57d8e7

commit r14-4165-g80048aa13a6b55d2be485000840a4e1c8b57d8e7
Author: Omar Sandoval <osandov@osandov.com>
Date:   Wed Sep 13 23:41:22 2023 -0700

    debug/111409 - don't generate COMDAT macro sections for split DWARF

    Split DWARF files aren't processed by the linker, so DW_MACRO_import
    offsets aren't relocated and the .debug_macro.dwo sections aren't
    deduplicated and merged.  There's no clear way for this to work for
    split DWARF, so disable it.

    gcc/ChangeLog:

            PR debug/111409
            * dwarf2out.cc (output_macinfo): Don't call optimize_macinfo_range
if
            dwarf_split_debug_info.

    gcc/testsuite/ChangeLog:

            PR debug/111409
            * gcc.dg/pr111409.c: New test.

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

* [Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
  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
  3 siblings, 0 replies; 5+ messages in thread
From: ro at gcc dot gnu.org @ 2023-11-28 12:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> ---
The new test FAILs on a couple of targets (sparc-sun-solaris2.11,
powerpc-ibm-aix7.2.5.0, hppa64-hp-hpux11.11).  I've commited a patch for the
Solaris/SPARC (and probably AIX) issue:

https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638456.html

HP/UX seems to be different, however.

Besides, is there a reason this PR is still open?

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

* [Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
  2023-09-13 21:29 [Bug debug/111409] New: Invalid .debug_macro.dwo macro information for split DWARF osandov at osandov dot com
                   ` (2 preceding siblings ...)
  2023-11-28 12:58 ` ro at gcc dot gnu.org
@ 2024-02-27  0:57 ` osandov at osandov dot com
  3 siblings, 0 replies; 5+ messages in thread
From: osandov at osandov dot com @ 2024-02-27  0:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

Omar Sandoval <osandov at osandov dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Omar Sandoval <osandov at osandov dot com> ---
Thanks for the test fix. I believe this is now resolved.

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

end of thread, other threads:[~2024-02-27  0:57 UTC | newest]

Thread overview: 5+ 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

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