Thanks so much for the detailed explanation. So clearly all the macros are
there as we can see from readelf. I ran it myself and can see all the
macros as David pointed out. And just to make sure I understand, this is
what I took away:
1. All the macros are in the file as we can see from readelf output.
2. As per the DWARF5 spec it states "As described in Section 3.1.1 on page
60, the macro information for a given compilation unit is represented in
the .debug_macro section of an object file."
Meaning that there should be only *one*.debug_macro section, not more
than 1 as gcc is structuring it.
3. So all of this points to gcc not outputting *all *of the aggregated
debug_macro sections into one for the DWARF consumers to consume it (when
it is an unlinked object file by itself)?
Am I correct in my understanding of what is happening here?
Again; thanks so much. If that is the case, I don't mind posting the bug on
the gcc issue tracker (which I assume is this one:
https://gcc.gnu.org/bugzilla/).
On Thu, Sep 12, 2024 at 1:39 PM David Blaikie <dblai...@gmail.com> wrote:
>
>
> On Thu, Sep 12, 2024 at 11:08 AM Jakub Jelinek <ja...@redhat.com> wrote:
>
>> On Thu, Sep 12, 2024 at 10:52:33AM -0700, David Blaikie via Dwarf-discuss
>> wrote:
>> > Looks probably like a bug in GCC and best discussed in their forum?
>> (clang
>> > seems to produce the macro in the macinfo if you compile with
>> > `-fdebug-macro` (& you have to put some emitted entity (like a function
>> > definition) in the file before Clang will produce any debug info for the
>> > file))
>>
>> GCC emits that the .debug_macro snippets from headers (in chunks
>> uninterrupted by inclusion of other headers) in .debug_macro comdat
>> sections
>> with wm4.0.6147fde142b63cfbd46fc3f1300479b2 etc. comdat groups and it is
>> just the linker which merges stuff back (and gets rid of redundancies).
>>
>
> Oooh, fascinating. Certainly llvm-dwarfdump has explicit support for
> sections it expects to be fragmented (multiple sections with the same name,
> for comdat purposes, etc) - and so llvm-dwarfdump certainly wouldn't dump
> this correctly (probably ignores all but the first section named
> `.debug_macro`) from an object file (of course in a linked executable, none
> of this still exists so it should be fine).
>
>
>>
>> So say for
>> /tmp/1.h
>> #define MAC4
>> #define MAC5 1
>> /tmp/1.c
>> #define MAC1 2
>> #define MAC2 3
>> #include "/tmp/1.h"
>> #define MAC3 4
>> int main () { return 0; }
>> gcc -O2 -g3 -c -o /tmp/1.o /tmp/1.c
>> gcc -o /tmp/1 /tmp/1.o
>> readelf -WS /tmp/1.o | grep debug_macro
>> [18] .debug_macro PROGBITS 0000000000000000 0001a4 00002c
>> 00 0 0 1
>> [19] .rela.debug_macro RELA 0000000000000000 003548 000090
>> 18 I 31 18 8
>> [20] .debug_macro PROGBITS 0000000000000000 0001d0 000934
>> 00 G 0 0 1
>> [21] .rela.debug_macro RELA 0000000000000000 0035d8 0024c0
>> 18 IG 31 20 8
>> [22] .debug_macro PROGBITS 0000000000000000 000b04 000010
>> 00 G 0 0 1
>> [23] .rela.debug_macro RELA 0000000000000000 005a98 000030
>> 18 IG 31 22 8
>> there are 2 extra .debug_macro sections in comdat groups, and then in the
>> resulting binary one has:
>> readelf -wm /tmp/1
>> Contents of the .debug_macro section:
>>
>> Offset: 0x0
>> Version: 5
>> Offset size: 4
>> Offset into .debug_line: 0x0
>>
>> DW_MACRO_import - offset : 0x2c
>> DW_MACRO_start_file - lineno: 0 filenum: 1
>> DW_MACRO_define_strp - lineno : 1 macro : MAC1 2
>> DW_MACRO_define_strp - lineno : 2 macro : MAC2 3
>> DW_MACRO_start_file - lineno: 3 filenum: 2
>> DW_MACRO_import - offset : 0x960
>> DW_MACRO_end_file
>> DW_MACRO_define_strp - lineno : 4 macro : MAC3 4
>> DW_MACRO_end_file
>> ...
>> Offset: 0x960
>> Version: 5
>> Offset size: 4
>>
>> DW_MACRO_define_strp - lineno : 1 macro : MAC4
>> DW_MACRO_define_strp - lineno : 2 macro : MAC5 1
>>
>> Left out the chunk at 0x2c, that is for predefined macros, for
>> showing how it works that is just a clutter.
>>
>> Jakub
>>
>>
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
