]> granicus.if.org Git - llvm/commit
[llvm-dwarfdump] - Do not error out on R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.
authorGeorge Rimar <grimar@accesssoftek.com>
Tue, 18 Dec 2018 12:15:01 +0000 (12:15 +0000)
committerGeorge Rimar <grimar@accesssoftek.com>
Tue, 18 Dec 2018 12:15:01 +0000 (12:15 +0000)
commita002f3a8ef004104e15c4047ec4a178f5884ab48
tree13a5845418cb804c784a4b2543a39919d906b3f9
parent7fe679909d1b1352152e9702e173d4ec0f696360
[llvm-dwarfdump] - Do not error out on R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.

This is https://bugs.llvm.org/show_bug.cgi?id=39992,

If we have the following code (test.cpp):

thread_local int tdata = 24;
and build an .o file with debug information:

clang --target=x86_64-pc-linux -c bar.cpp -g

Then object produced may have R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.
(clang emits R_X86_64_DTPOFF64 and gcc emits R_X86_64_DTPOFF32 for the code above for me)

Currently, llvm-dwarfdump fails to compute this TLS relocation when dumping
object and reports an
error:
failed to compute relocation: R_X86_64_DTPOFF64, Invalid data was encountered while parsing the file

This relocation represents the offset in the TLS block and resolved by the linker,
but this info is unavailable at the
point when the object file is dumped by this tool.

The patch adds the simple evaluation for such relocations to avoid emitting errors.
Resulting behavior seems to be equal to GNU dwarfdump.

Differential revision: https://reviews.llvm.org/D55762

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@349476 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Object/RelocVisitor.h
test/tools/llvm-dwarfdump/X86/debug_tls_relocs.s [new file with mode: 0644]