<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 12, 2024 at 11:08 AM Jakub Jelinek <<a href="mailto:jakub@redhat.com">jakub@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 12, 2024 at 10:52:33AM -0700, David Blaikie via Dwarf-discuss wrote:<br>
> Looks probably like a bug in GCC and best discussed in their forum? (clang<br>
> seems to produce the macro in the macinfo if you compile with<br>
> `-fdebug-macro` (& you have to put some emitted entity (like a function<br>
> definition) in the file before Clang will produce any debug info for the<br>
> file))<br>
<br>
GCC emits that the .debug_macro snippets from headers (in chunks<br>
uninterrupted by inclusion of other headers) in .debug_macro comdat sections<br>
with wm4.0.6147fde142b63cfbd46fc3f1300479b2 etc. comdat groups and it is<br>
just the linker which merges stuff back (and gets rid of redundancies).<br></blockquote><div><br>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). <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So say for<br>
/tmp/1.h<br>
#define MAC4<br>
#define MAC5 1<br>
/tmp/1.c<br>
#define MAC1 2<br>
#define MAC2 3<br>
#include "/tmp/1.h"<br>
#define MAC3 4<br>
int main () { return 0; }<br>
gcc -O2 -g3 -c -o /tmp/1.o /tmp/1.c<br>
gcc -o /tmp/1 /tmp/1.o<br>
readelf -WS /tmp/1.o | grep debug_macro<br>
[18] .debug_macro PROGBITS 0000000000000000 0001a4 00002c 00 0 0 1<br>
[19] .rela.debug_macro RELA 0000000000000000 003548 000090 18 I 31 18 8<br>
[20] .debug_macro PROGBITS 0000000000000000 0001d0 000934 00 G 0 0 1<br>
[21] .rela.debug_macro RELA 0000000000000000 0035d8 0024c0 18 IG 31 20 8<br>
[22] .debug_macro PROGBITS 0000000000000000 000b04 000010 00 G 0 0 1<br>
[23] .rela.debug_macro RELA 0000000000000000 005a98 000030 18 IG 31 22 8<br>
there are 2 extra .debug_macro sections in comdat groups, and then in the<br>
resulting binary one has:<br>
readelf -wm /tmp/1<br>
Contents of the .debug_macro section:<br>
<br>
Offset: 0x0<br>
Version: 5<br>
Offset size: 4<br>
Offset into .debug_line: 0x0<br>
<br>
DW_MACRO_import - offset : 0x2c<br>
DW_MACRO_start_file - lineno: 0 filenum: 1<br>
DW_MACRO_define_strp - lineno : 1 macro : MAC1 2<br>
DW_MACRO_define_strp - lineno : 2 macro : MAC2 3<br>
DW_MACRO_start_file - lineno: 3 filenum: 2<br>
DW_MACRO_import - offset : 0x960<br>
DW_MACRO_end_file<br>
DW_MACRO_define_strp - lineno : 4 macro : MAC3 4<br>
DW_MACRO_end_file<br>
...<br>
Offset: 0x960<br>
Version: 5<br>
Offset size: 4<br>
<br>
DW_MACRO_define_strp - lineno : 1 macro : MAC4 <br>
DW_MACRO_define_strp - lineno : 2 macro : MAC5 1<br>
<br>
Left out the chunk at 0x2c, that is for predefined macros, for<br>
showing how it works that is just a clutter.<br>
<br>
Jakub<br>
<br>
</blockquote></div></div>