George Rimar cde43c9fdd [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 llvm-svn: 349476		2018-12-18 12:15:01 +00:00
..
X86	[llvm-dwarfdump] - Do not error out on R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.	2018-12-18 12:15:01 +00:00
cmdline.test	[dwarfdump] Make incompatibility between -diff and -verbose explicit.	2018-10-23 21:51:44 +00:00
lit.local.cfg	llvm-dwarfdump: support dumping UUIDs of Mach-O binaries.	2017-09-13 18:22:59 +00:00
uuid32.yaml	dwarfdump: Match the --uuid output with that of Darwin dwarfdump.	2018-01-05 21:44:17 +00:00
uuid.yaml	dwarfdump: Match the --uuid output with that of Darwin dwarfdump.	2018-01-05 21:44:17 +00:00