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
