Hello!
I am trying to understand something unexpected I am seeing in the relocations
placed into a compiled Linux kernel for the .debug_info section. Those
relocations seem to change the names of various entries in the debug info:
[65] .debug_info PROGBITS 0000000000000000 02c284e0
000000000c458644 0000000000000000 0 0 1
[66] .rela.debug_info RELA 0000000000000000 16081790
000000001288ae68 0000000000000018 I 78 65 8
[72] .debug_str PROGBITS 0000000000000000 10b451e8
00000000002bef2e 0000000000000001 MS 0 0 1
Dumping the DWARF information for one of the CUs in the compiled image (with
standard tooling) shows me:
0x0000002d: DW_TAG_compile_unit
DW_AT_producer ("GNU C89 8.3.1 20191121 (Red Hat 8.3.1-5)
-mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -mno-80387
-mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
-mno-red-zone -mcmodel=kernel -mindirect-branch=thunk-extern
-mindirect-branch-register -mrecord-mcount -mfentry -march=x86-64 -g -gdwarf-4
-O2 -std=gnu90 -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-falign-jumps=1 -falign-loops=1 -funit-at-a-time
-fno-asynchronous-unwind-tables -fno-jump-tables
-fno-delete-null-pointer-checks -fstack-protector-strong
-fno-inline-functions-called-once -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fstack-check=no -fconserve-stack --param
allow-store-data-races=0")
DW_AT_language (DW_LANG_C89)
DW_AT_name ("arch/x86/kernel/head64.c")
DW_AT_comp_dir
("/usr/src/debug/kernel-4.18.0-193.el8/linux-4.18.0-193.el8.x86_64")
DW_AT_ranges (0x000009d0
[0xffffffff81002000, 0xffffffff81002008)
[0xffffffff82977172, 0xffffffff829771c0)
[0xffffffff829771c0, 0xffffffff8297727a)
[0xffffffff8297727a, 0xffffffff829774f8)
[0xffffffff829774f8, 0xffffffff82977518)
[0xffffffff82977518, 0xffffffff8297759f)
[0xffffffff81000200, 0xffffffff810005b9)
[0xffffffff8297759f, 0xffffffff829775bc))
DW_AT_low_pc (0x0000000000000000)
DW_AT_stmt_list (0x00000126)
0x00000d84: DW_TAG_structure_type [55] *
DW_AT_name [DW_FORM_strp] (
.debug_str[0x0023ff94] = "task_struct")
DW_AT_byte_size [DW_FORM_data2] (0x2480)
DW_AT_alignment [DW_FORM_data1] (0x40)
DW_AT_decl_file [DW_FORM_data1]
("/usr/src/debug/kernel-4.18.0-193.el8/linux-4.18.0-193.el8.x86_64/./include/linux/sched.h")
DW_AT_decl_line [DW_FORM_data2] (589)
DW_AT_decl_column [DW_FORM_data1] (0x08)
DW_AT_sibling [DW_FORM_ref4] (cu + 0x19cc =>
{0x000019ee})
As I'd expect, the name of the structure with the DWARF DIE at offset 0xd84 is
"task_struct". A hex dump of this part of .debug_info within the compiled
image confirms the 0x23ff94 offset into the string table:
02c29260 47 0d 00 00 37 **94 ff 23 00** 80 24 40 22 4d 02 08
|G...7..#..$@"M..|
02c29270 cc 19 00 00 02 28 a5 19 00 22 53 02 16 bb 49 00
|.....(..."S...I.|
02c29280 00 00 02 77 0a 11 00 22 56 02 12 bd 01 00 00 10
|...w..."V.......|
02c29290 02 c6 07 15 00 22 5e 02 0b 8b 05 00 00 18 02 26
|....."^........&|
And dumping this area of .debug_str shows the name I'd expect (0x23ff94 within
.debug_str is 0x10d8517c)
10d85168 61 73 6b 5f 73 74 72 75 63 74 00 61 72 63 68 5f
|ask_struct.arch_|
10d85178 64 75 70 5f **74 61 73 6b 5f 73 74 72 75 63 74 00 **
|dup_task_struct.|
10d85188 5f 5f 6b 73 79 6d 74 61 62 5f 5f 5f 70 75 74 5f
|__ksymtab___put_|
10d85198 74 61 73 6b 5f 73 74 72 75 63 74 00 5f 5f 6b 73
|task_struct.__ks|
The relocations within .rela.debug_info, however, change the STRP reference for
the "task_struct" DIE to something else:
Relocation section '.rela.debug_info' at offset 0x16081790 contains
12956143 entries:
Offset Info Type Sym. Value Sym. Name +
Addend
000000000d85 002a0000000a R_X86_64_32 0000000000000000 .debug_str +
66d60
Looking at offset 0x66d60 into .debug_str shows the middle of some other random
name (0x66d60 in would be 0x10babf48): "ksymtab_power_supply_get_drvdata" in
this case.
10babf38 76 5f 67 65 74 5f 64 72 76 64 61 74 61 00 5f 5f
|v_get_drvdata.__|
10babf48 6b 73 79 6d 74 61 62 5f 70 6f 77 65 72 5f 73 75
|ksymtab_power_su|
10babf58 70 70 6c 79 5f 67 65 74 5f 64 72 76 64 61 74 61
|pply_get_drvdata|
10babf68 00 5f 5f 6b 73 74 72 74 61 62 5f 70 6f 77 65 72
|.__kstrtab_power|
Have I misunderstood something fundamental here about the relocation data in
.rela.debug_info and its application...? Or is the relocation data in this
.rela.debug_info bad...?
If there is a better mailing list for me to ask such a question, I'd be happy
for a redirect.
Sincerely,
Bill Messmer
