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