-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
debug/elf: DWARF relocations should not always be applied #46673
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
ianlancetaylor
added
the
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
label
Jun 10, 2021
I think it would be fine to skip the apply-relocations step for an |
vikmik
added a commit
to vikmik/go
that referenced
this issue
Jun 11, 2021
Some ET_EXEC binaries might have relocations for non-loadable sections like .debug_info. These relocations must not be applied, because: * They may be incorrect * The correct relocations were already applied at link time Binaries in Linux Kernel debug packages like Fedora/Centos kernel-debuginfo are such examples. Relocations for .debug_* sections are included in the final binaries because they are compiled with --emit-relocs, but the resulting relocations are incorrect and shouldn't be used when reading DWARF sections. Fixes golang#46673
Change https://golang.org/cl/327009 mentions this issue: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?What did you do?
Download and extract https://www.rpmfind.net/linux/fedora/linux/updates/34/Everything/x86_64/debug/Packages/k/kernel-debuginfo-5.12.9-300.fc34.x86_64.rpm
( to extract with
rpm2cpio
in the current directory:rpm2cpio kernel-debuginfo-5.12.9-300.fc34.x86_64.rpm | cpio -idmv
)Then run the following code (change the path as needed)
What did you expect to see?
arch_local_irq_restore
Why? This is what llvm-dwarfdump prints for the DW_AT_name attribute for the DIE at offset 0x00c24858:
What did you see instead?
CK__tp_func_mce_record430
What seems to be the problem:
Note: this is a kernel debug file. It is compiled with
--emit-relocs
because of KASLR, and as a result has relocations for everythingThe apparent problem is that the relocations for the .debug_str offsets in .rela.debug_info do not match the corresponding values in .debug_info. Let's illustrate that with the following:
Notice the DW_AT_name value, which points to
.debug_str + 0x001dd207
Now let's look at the relocations for this attribute (it is in
.rela.debug_info
). Adding 1 to 0x00c24858 (the offset of the DIE) to find the offset of the DW_AT_name attribute in.debug_info
:=> after relocations are applied, the DW_AT_name attribute points to
.debug_str + 883e
.Dumping the contents of
.debug_string
at that offset, we indeed find the non-sensical output (CK__tp_func_mce_record430
):The most relevant discussion I found on the internet is the following thread:
https://gcc.gnu.org/pipermail/gcc/2020-December/234392.html
I have 2 take-aways from this:
dwarfdump
,llvm-dwarfdump
and various symbolizers do not apply relocations for this.For example,
addr2line -f -e ./usr/lib/debug/lib/modules/5.12.9-300.fc34.x86_64/vmlinux 0xffffffff8106bcf1
looks up the same DW_AT_name attribute and correctly outputs "arch_local_irq_restore".So it seems that the recommendation from this is "do not apply DWARF rela relocations when the binary is ET_EXEC".
I just want to discuss whether you think this is a reasonable way forward (@ianlancetaylor , you seem to be the one looking at these parts of the code these days? :) ). I'll be happy to contribute a fix after discussion here
The text was updated successfully, but these errors were encountered: