[Bug debug/99319] New: DW_MACRO_define_strp uses uleb128 for second operand

[Bug debug/99319] New: DW_MACRO_define_strp uses uleb128 for second operand

[vries at gcc dot gnu.org]

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

            Bug ID: 99319
           Summary: DW_MACRO_define_strp uses uleb128 for second operand
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider compiling hello world, with macro info:
...
$ gcc-11 -ggdb3 -g hello.c -dA -save-temps
...

In a-hello.s, we have:
...
        .section        .debug_macro,"",@progbits
.Ldebug_macro0:
        .value  0x5     # DWARF macro version number
        .byte   0x2     # Flags: 32-bit, lineptr present
        .long   .Ldebug_line0
        .byte   0x3     # Start new file
        .uleb128 0      # Included from line number 0
        .uleb128 0x1    # file hello.c
        .byte   0x5     # Define macro strp
        .uleb128 0      # At line number 0
        .long   .LASF2  # The macro: "__STDC__ 1"
...

So, the DW_MACRO_define_strp entry (starting with .byte 0x5) has two operands,
a uleb128 and a .long.

AFAIU, this is in accordance with the spec:
...
A DW_MACRO_define_strp or DW_MACRO_undef_strp entry has two operands. The first
operand encodes the source line number of the #define or #undef macro
directive. The second operand consists of an offset into a string table
contained in the .debug_str section of the object file. The size of the operand
is given in the header offset_size_flag field.
...

Now add -gsplit-dwarf:
...
$ gcc-11 -ggdb3 -g hello.c -dA -save-temps -gsplit-dwarf
...

Now we have instead:
...
        .section        .debug_macro.dwo,"e",@progbits
.Ldebug_macro0:
        .value  0x5     # DWARF macro version number
        .byte   0x2     # Flags: 32-bit, lineptr present
        .long   .Lskeleton_debug_line0
        .byte   0x3     # Start new file
        .uleb128 0      # Included from line number 0
        .uleb128 0x1    # file hello.c
        .byte   0x5     # Define macro strp
        .uleb128 0      # At line number 0
        .uleb128 0x191  # The macro: "__STDC__ 1"
...

The second operand is now also a .uleb128.  AFAIU, this goes against the spec.

[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Related readelf PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27387

[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> The second operand is now also a .uleb128.  AFAIU, this goes against the
> spec.

Also, gdb doesn't get it:
...
$ gdb -q -batch -readnow a.out
DW_FORM_strp pointing outside of .debug_str section [in module
/home/vries/hello/a.out]
...

Debugging shows that the error is due to a large str_offset:
...
(gdb) p /x str_offset
$14 = 0x8c0502cd
...
which matches this:
...
        .byte   0x5     # Define macro strp
        .uleb128 0x8b   # At line number 139
        .uleb128 0x14d  # The macro: "stdin stdin"
        .byte   0x5     # Define macro strp
        .uleb128 0x8c   # At line number 140
        .uleb128 0x24   # The macro: "stdout stdout"
...

Note that the uleb128 representation of 0x14d is "cd02".

[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-03-01
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 50274
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50274&action=edit
gcc11-pr99319.patch

Ugh, this is a mess.  Seems r0-120109-g99ea153e45c86a1b0318e3f5e983624c3336445e
that introduced the DWARF 4 -gsplit-dwarf extension came after I've introduced
.debug_macro also as DWARF 4 extension, but not too long after it so it hasn't
thought out interactions very well.  So, I'm afraid for version 4
.debug_macro.dwo consumers should expect 2 leb128 arguments instead of one +
offse.  And for DWARF 5 we have the standardized DW_MACRO_*_strx which make
those explicit, so this patch changes GCC to emit that.

[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5a233ae4d8c978a3c863c8199d6c3050389a84d1

commit r11-7457-g5a233ae4d8c978a3c863c8199d6c3050389a84d1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 2 18:25:45 2021 +0100

    dwarf2out: Fix up split-dwarf .debug_macro handling [PR99319]

    The -gsplit-dwarf changes came a few months after .debug_macro
    and the r0-120109 changes just changed the 2nd operand of
    DW_MACRO_GNU_{define,undef}_indirect from the usual .debug_str
    section offset argument to leb128 index into .debug_str_offsets
    without changing the opcodes.

    DWARF5 standardized different opcodes for those, but GCC hasn't been
changed
    yet for that.
    This patch starts using DW_MACRO_define_strx and DW_MACRO_undef_strx
    instead of DW_MACRO_define_strp and DW_MACRO_undef_strp when -gsplit-dwarf
    -gdwarf-5 -g3.  I'm not sure what to do if anything with the -gdwarf-4
    -gsplit-dwarf -g3 -gno-strict-dwarf case, we've been emitting it that way
    for 8 years and it is an extension, so presumably the consumers that cared
    have already hacks to handle DW_MACRO_GNU_{define,undef}_indirect
    differently in .debug_macro 4 sections depending on if it is
    .debug_macro.dwo or .debug_macro.
    Another change the patch does is that it will use
    DW_MACRO_{define,undef}_str{p,x} even with -gdwarf-5 -gstrict-dwarf -g3,
    for DWARF 4 we were doing that only for -gno-strict-dwarf as we've emitted
    .debug_macro section only in that case.

    2021-03-02  Jakub Jelinek  <jakub@redhat.com>

            PR debug/99319
            * dwarf2out.c (output_macinfo_op): Use DW_MACRO_*_str* even with
            -gdwarf-5 -gstrict-dwarf.  For -gsplit-dwarf -gdwarf-5 use
            DW_MACRO_*_strx instead of DW_MACRO_*_strp.  Handle
            DW_MACRO_define_strx and DW_MACRO_undef_strx.
            (save_macinfo_strings): Use DW_MACRO_*_str* even with
            -gdwarf-5 -gstrict-dwarf.  Handle DW_MACRO_define_strx and
            DW_MACRO_undef_strx.

[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for GCC 11.