This is an archive of the discontinued LLVM Phabricator instance.

[llvm-dwarfdump] - Do not error out on R_X86_64_DTPOFF64/R_X86_64_DTPOFF32 relocations.
ClosedPublic

Authored by grimar on Dec 17 2018, 4:56 AM.

Details

Summary

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, it dumps the locations without errors in the same way:

< 1><0x00000016>    DW_TAG_variable
                      DW_AT_name                  X
                      DW_AT_type                  <0x00000000>
                      DW_AT_external              yes(1)
                      DW_AT_location              len 0x000a: 0e0000000000000000e0: DW_OP_const8u 0 DW_OP_GNU_push_tls_address
< 1><0x0000002a>    DW_TAG_variable
                      DW_AT_name                  X
                      DW_AT_type                  <0x00000000>
                      DW_AT_external              yes(1)
                      DW_AT_location              len 0x0006: 0c00000000e0: DW_OP_const4u 0 DW_OP_GNU_push_tls_address

Diff Detail

Event Timeline

grimar created this revision.Dec 17 2018, 4:56 AM

Note that if addends are involved, i.e. we have:

	.quad	tdata1 + 0x11@DTPOFF
...
	.long	tdata2 + 0x22@DTPOFF

Then GNU dwarfdump prints them:

LOCAL_SYMBOLS:
< 1><0x00000016>    DW_TAG_variable
                      DW_AT_name                  X
                      DW_AT_type                  <0x00000000>
                      DW_AT_external              yes(1)
                      DW_AT_location              len 0x000a: 0e1100000000000000e0: DW_OP_const8u 17 DW_OP_GNU_push_tls_address
< 1><0x0000002a>    DW_TAG_variable
                      DW_AT_name                  X
                      DW_AT_type                  <0x00000000>
                      DW_AT_external              yes(1)
                      DW_AT_location              len 0x0006: 0c22000000e0: DW_OP_const4u 34 DW_OP_GNU_push_tls_address

But llvm-dwarfdump don't. This might be a separate issue perhaps. I did not include addends into the test case.

dblaikie accepted this revision.Dec 17 2018, 10:53 AM

Sounds alright to me - thanks!

This revision is now accepted and ready to land.Dec 17 2018, 10:53 AM
This revision was automatically updated to reflect the committed changes.