<div dir="ltr"><div>I did find it kind of odd too that it emitted "macinfo". I got a newer version of clang(Ubuntu clang version 14.0.0-1ubuntu1.1 ) and now it actually emits the DWARF5 version of macros:</div><div><br></div><div>.debug_macro: Macro info for a single cu at macro Offset 0x00000000<br>Macro data from CU-DIE at .debug_info offset 0x0000000c:<br> Nested import level: 0<br> Macro version : 5<br> macro section offset 0x00000000<br> MacroInformationEntries count: 371, bytes length: 1350<br> [ 0] 0x03 DW_MACRO_start_file line 0 file number 0 /home/docker/juicer/src/macro_test.c<br> [ 1] 0x0b DW_MACRO_define_strx line 1 str offset 0x00000081 __clang__ 1<br> [ 2] 0x0b DW_MACRO_define_strx line 2 str offset 0x0000004c main<br> [ 3] 0x03 DW_MACRO_start_file line 3 file number 1 /home/docker/juicer/src/./macro_test.h<br> [ 4] 0x0b DW_MACRO_define_strx line 1 str offset 0x00000081 __clang__ 1<br> [ 5] 0x0b DW_MACRO_define_strx line 2 str offset 0x00000051 int<br> [ 6] 0x04 DW_MACRO_end_file <br> [ 7] 0x0b DW_MACRO_define_strx line 4 str offset 0x00000051 int<br> [ 8] 0x04 DW_MACRO_end_file <br></div><div>....</div><div><br></div><div><br></div><div>Makes sense. Thanks so much for the detailed explanations. You're right; clang doesn't seem to be writing the DW_MACRO_import at all (at least judging from the dwarfdump output).</div><div><br></div><div>I also learned something about libdwarf, which makes me feel silly now. I can actually get the different macros from the different COMDAT sections using the </div><div><br></div><div>int dwarf_init_b(int /*fd*/,<br> Dwarf_Unsigned /*access*/,<br> unsigned /*groupnumber*/,<br> Dwarf_Handler /*errhand*/,<br> Dwarf_Ptr /*errarg*/,<br> Dwarf_Debug* /*dbg*/,<br> Dwarf_Error* /*error*/);</div><div><br></div><div>function and passing the groupnumber I'm interested in. I was previously using the "dwarf_init" function, which does not have an argument for the group number.<br></div><div><br></div><div>Hopefully this helps someone out there if they find themselves struggling with this.</div><div><br></div><div>Thanks for all your help everybody!<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2024 at 3:01 PM Jakub Jelinek <<a href="mailto:jakub@redhat.com" target="_blank">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 Fri, Sep 13, 2024 at 01:46:26PM -0500, Lorenzo Gomez wrote:<br>
> That makes sense. Interestingly enough when I run with clang<br>
> "clang -gdwarf-5 -fdebug-macro -g3 -c macro_test.c -o macro_test_clang.o"<br>
> and dwarfdump with "dwarfdump macro_test_clang.o > macro_test_clang_dwarf"<br>
> <br>
> yields all the macros:<br>
> <br>
> <br>
> compilation-unit .debug_macinfo offset 0x00000000<br>
<br>
That seems to be .debug_macinfo, i.e. the DWARF4-ish section.<br>
In that case, there is no other choice but to emit all the macros.<br>
<br>
> num name section-offset file-index [line] "string"<br>
> 0 DW_MACINFO_start_file: 0 0 [ 0] 0<br>
> 1 DW_MACINFO_define : 3 0 [ 1] "MAC1 2"<br>
> 2 DW_MACINFO_define : 12 0 [ 2] "MAC2 3"<br>
> 3 DW_MACINFO_start_file: 21 1 [ 3] 0<br>
> 4 DW_MACINFO_define : 24 1 [ 1] "MAC4"<br>
> 5 DW_MACINFO_define : 31 1 [ 2] "MAC5 1"<br>
> 6 DW_MACINFO_end_file : 40 1 [ 0] 0<br>
> 7 DW_MACINFO_define : 41 0 [ 4] "MAC3 4"<br>
> 8 DW_MACINFO_end_file : 50 0 [ 0] 0<br>
<br>
The design of .debug_macro is to decrease around 100x times the size<br>
of the section by a) using references to .debug_str strings instead of<br>
including the strings directly in the section, which allows getting rid of<br>
reduncanies in the macro names/values between different compilation units<br>
b) using the DW_MACRO_import to get rid of redundancies even in the ops<br>
coming from the same header as long as it defines the same macros (which<br>
usually is the case).<br>
GCC implements both, clang apparently implements just a).<br>
Consider say simple testcase like:<br>
#define DEF 2<br>
#include <stdio.h><br>
#define ABC 1<br>
int i;<br>
With GCC that results in 400 bytes in the non-group .debug_macro<br>
(i.e. unsharable) and 5341 bytes in the group .debug_macro sections<br>
(part in stdio.h related stuff (and headers it includes), part in<br>
predefined macros), that is sharable by different CUs most likely.<br>
If the #include is commented out, it reduces to 38 bytes in the primary<br>
.debug_macro and 2774 bytes in group .debug_macro sections (so that maps<br>
the predefined macros).<br>
Compare to clang 3723 .debug_macro section size (unsharable) plus<br>
3372 .debug_str_addr (admittedly shared with .debug_info, but otherwise<br>
also unsharable with other CUs) vs. with #include commented out<br>
1765 .debug_macro and 1904 .debug_str_addr. Note, GCC uses more<br>
relocations, which makes larger *.o files but if the most important<br>
is debug info in linked binaries/shared libraries, by using heavily<br>
DW_MACRO_import you can have those 5341-2774 bytes for stdio.h usually<br>
just once in a binary, rather than number of CUs that include it.<br>
<br>
> <br>
> clang version:<br>
> clang version 10.0.0-4ubuntu1<br>
<br>
That seems to be fairly old.<br>
<br>
Jakub<br>
<br>
</blockquote></div>