<div dir="ltr"><div>That makes sense. Interestingly enough when I run with clang <br></div><div>"clang -gdwarf-5 -fdebug-macro -g3 -c macro_test.c -o macro_test_clang.o"</div><div>and dwarfdump with "dwarfdump macro_test_clang.o > macro_test_clang_dwarf"</div><div><br></div><div>yields all the macros:</div><div><br></div><div><br></div><div>compilation-unit .debug_macinfo offset 0x00000000<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</div><div><br></div><div>clang version:</div><div>clang version 10.0.0-4ubuntu1 <br>Target: x86_64-pc-linux-gnu<br>Thread model: posix<br>InstalledDir: /usr/bin<br></div><div><br></div><div><br></div><div>Lorenzo<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2024 at 11:38 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 Fri, Sep 13, 2024 at 10:51:33AM -0500, Lorenzo Gomez wrote:<br>
> Thanks again for all of the insight into all this. The reason we're looking<br>
> into this is because we develop a tool that extracts dwarf info from an elf<br>
> file called juicer <<a href="https://github.com/WindhoverLabs/juicer" rel="noreferrer" target="_blank">https://github.com/WindhoverLabs/juicer</a>>, which dumps<br>
> it into a SQLITE db for other tools. And we want to make sure we document<br>
> all the various cases when it comes to different types of object<br>
> files(shared, object file, executable/linked, etc) so that our users are<br>
> aware of all of this.<br>
> <br>
> In any case it looks I can apply relocations with the "-r" switch in gcc<br>
> and I tried the following:<br>
> <br>
> gcc -r macro_test.o -o macro_test_relocatable<br>
<br>
gcc -r is a relocatable partial link, not applying relocations. Given that<br>
the different .debug_macro sections are in different comdat group, such<br>
relocations can't be resolved.<br>
<br>
> As you mentioned there is the "DW_MACRO_import", but it has an offset of<br>
> "0x00000000". Which, if I'm interpreting the DWARF5 spec correctly, means<br>
> "end of macros" for macro import units (and we still don't get the "MAC4",<br>
> "MAC5" macros). And this makes sense in that this is what<br>
> "dwarf_get_macro_import" returns when I step through code in juicer. And I<br>
> believe that dwarfdump is using libdwarf too so that makes sense.<br>
<br>
DW_MACRO_import 0 means include the .debug_macro chunk from offset 0<br>
in the section, which with applied relocations would be endless recursion<br>
there.<br>
Most likely just dwarfdump doesn't distinguish in that 0x00000000 what it<br>
really is, it is really a relocation against .debug_macro+0, but not the<br>
current .debug_macro, but .debug_macro in a different comdat group.<br>
Admittedly, neither does readelf nor eu-readelf nor objdump.<br>
You need to look up the relocations manually, e.g. readelf -wm -r will print<br>
those (or even better just use some library which can handle all that stuff,<br>
wonder if libdw does).<br>
In my case, the first .debug_macro (not in comdat group) has<br>
Relocation section '.rela.debug_macro' at offset 0x3548 contains 6 entries:<br>
Offset Info Type Symbol's Value Symbol's Name + Addend<br>
0000000000000003 000000080000000a R_X86_64_32 0000000000000000 .debug_line + 0<br>
0000000000000008 0000000b0000000a R_X86_64_32 0000000000000000 .debug_macro + 0<br>
0000000000000011 000000090000000a R_X86_64_32 0000000000000000 .debug_str + 1b44<br>
0000000000000017 000000090000000a R_X86_64_32 0000000000000000 .debug_str + 400<br>
000000000000001f 0000000c0000000a R_X86_64_32 0000000000000000 .debug_macro + 0<br>
0000000000000026 000000090000000a R_X86_64_32 0000000000000000 .debug_str + 1370<br>
relocations, and<br>
Symbol table '.symtab' contains 16 entries:<br>
Num: Value Size Type Bind Vis Ndx Name<br>
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND <br>
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS 1.c<br>
2: 0000000000000000 0 SECTION LOCAL DEFAULT 6 .text.startup<br>
3: 0000000000000000 0 SECTION LOCAL DEFAULT 7 .debug_frame<br>
4: 0000000000000000 0 SECTION LOCAL DEFAULT 11 .debug_info<br>
5: 0000000000000000 0 SECTION LOCAL DEFAULT 13 .debug_abbrev<br>
6: 0000000000000000 0 SECTION LOCAL DEFAULT 16 .debug_rnglists<br>
7: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .debug_macro<br>
8: 0000000000000000 0 SECTION LOCAL DEFAULT 24 .debug_line<br>
9: 0000000000000000 0 SECTION LOCAL DEFAULT 26 .debug_str<br>
10: 0000000000000000 0 SECTION LOCAL DEFAULT 27 .debug_line_str<br>
11: 0000000000000000 0 SECTION LOCAL DEFAULT 20 .debug_macro<br>
12: 0000000000000000 0 SECTION LOCAL DEFAULT 22 .debug_macro<br>
13: 0000000000000000 0 NOTYPE LOCAL DEFAULT 1 wm4.0.6147fde142b63cfbd46fc3f1300479b2<br>
14: 0000000000000000 0 NOTYPE LOCAL DEFAULT 2 wm4.1.h.1.24d259e5524e60c87a9b7b969ac9e698<br>
15: 0000000000000000 3 FUNC GLOBAL DEFAULT 6 main<br>
and<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>
So, the first DW_MACRO_import relocation is with symbol 0xb, i.e.<br>
.debug_macro section 20, while the second one 0xc, so .debug_macro section<br>
22. The first one is in wm4.0.6147fde142b63cfbd46fc3f1300479b2 comdat group<br>
and second in wm4.1.h.1.24d259e5524e60c87a9b7b969ac9e698 comdat group.<br>
<br>
Note, this isn't just about .debug_macro section, if you look at .debug_info<br>
in the relocatable object, e.g. dwarfdump prints there:<br>
DW_AT_low_pc 0x00000000<br>
DW_AT_stmt_list 0x00000000<br>
DW_AT_macros 0x00000000<br>
(though for ranges prints it inline:<br>
DW_AT_ranges 0x0000000c<br>
<br>
Offset of rnglists entries: 0x0000000c<br>
[ 0] start,end 0x00000000 0x00000003<br>
[ 1] end of list <br>
).<br>
readelf -wi doesn't either, but at least prints the offset and one can look<br>
up the relocations manually:<br>
<1a> DW_AT_ranges : 0xc<br>
<1e> DW_AT_low_pc : 0x0<br>
<26> DW_AT_stmt_list : 0x0<br>
<2a> DW_AT_macros : 0x0<br>
00000000001a 00060000000a R_X86_64_32 0000000000000000 .debug_rnglists + c<br>
000000000026 00080000000a R_X86_64_32 0000000000000000 .debug_line + 0<br>
00000000002a 00070000000a R_X86_64_32 0000000000000000 .debug_macro + 0<br>
but again when there are multiple sections with the same name in different<br>
comdat groups, one can't really visually differentiate between the different<br>
sections unless looking up the exact symbol.<br>
<br>
All the tools are designed primarily with non-relocatable objects (i.e.<br>
binaries and shared libraries) in mind...<br>
<br>
Jakub<br>
<br>
</blockquote></div>