[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed for GCC 11.
[Bug debug/99319] DW_MACRO_define_strp uses uleb128 for second operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5a233ae4d8c978a3c863c8199d6c3050389a84d1
commit r11-7457-g5a233ae4d8c978a3c863c8199d6c3050389a84d1
Author: Jakub Jelinek
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 Jakub Jelinek 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 --- Created attachment 50274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50274=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 --- Comment #2 from Tom de Vries --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319 --- Comment #1 from Tom de Vries --- Related readelf PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27387
