This program fails to link when compiling with debugging info (-g): __thread int x; int main(){} It fails with the following message from the linker: /usr/bin/aarch64-linux-gnu-ld: /tmp/test2-67df6a.o(.debug_info+0x37): R_AARCH64_ABS64 used with TLS symbol x
I can reproduce this with ld.bfd, but not with ld.gold. This looks like an ld.bfd bug to me. Details: $ clang-3.5 -g -o t.clang35 t.c -Wl,-v GNU gold (GNU Binutils for Debian 2.25) 1.11 $ clang-3.5 -g -o t.clang35 t.c -fuse-ld=bfd -Wl,-v GNU ld (GNU Binutils for Debian) 2.25 /usr/bin/ld.bfd: /tmp/t-79ee56.o(.debug_info+0x37): R_AARCH64_ABS64 used with TLS symbol x
I thought it might be a clang bug because gcc does not use this relocation type when generating the debug info for this same file.
> gcc does not use this relocation type when generating the debug info for this same file I was just going to ask about that. I can't easily test with GCC/AArch64 - what relocation type does it use for this debug info?
Created attachment 13974 [details] Assembly generated by GCC Here is the output generated by gcc for a slightly modified version of the test program (removed main and renamed TLS variable to xxx). It doesn't seem to use any relocations, whereas clang has ".xword xxx" in the debug info which refers to the TLS variable.
Created attachment 13975 [details] Assembly generated by Clang Here is the assembly generated by clang, for reference.
for x86 at least, I did hit a bug with bfd ld not supporting the 64 bit debug tls relocation, but it did support the 32. GCC would produce a zero word, then a 32 bit relocation, whereas I implemented clang to produce the 64 bit reloc because it was a bit simpler to do it that way. I think there was a comment/bug/commit somewhere that was about 10 years old suggesting that such support could be added, but no action seemed to have occurred on that front. The gold linker didn't seem to have this 64 bit problem.
David - which "64 bit debug TLS relocation" do you mean? On amd64 I see the same relocation for a TLS and non-TLS variable (on FreeBSD base system Clang 3.4.1 or Clang SVN head) test.c === __thread int xxx; int yyy; int main(){} === Relocation section with addend (.rela.debug_info): r_offset r_info r_type st_value st_name + r_addend 000000000034 001400000001 R_X86_64_64 0000000000000000 xxx + 0 000000000052 001500000001 R_X86_64_64 0000000000000004 yyy + 0 (In reply to comment #0) > This program fails to link when compiling with debugging info (-g): > __thread int x; > int main(){} > > It fails with the following message from the linker: > /usr/bin/aarch64-linux-gnu-ld: /tmp/test2-67df6a.o(.debug_info+0x37): > R_AARCH64_ABS64 used with TLS symbol x
(In reply to comment #7) > David - which "64 bit debug TLS relocation" do you mean? > > On amd64 I see the same relocation for a TLS and non-TLS variable (on > FreeBSD base system Clang 3.4.1 or Clang SVN head) > > test.c > === > __thread int xxx; > int yyy; > int main(){} > === > > Relocation section with addend (.rela.debug_info): > r_offset r_info r_type st_value st_name + > r_addend > 000000000034 001400000001 R_X86_64_64 0000000000000000 xxx + 0 > 000000000052 001500000001 R_X86_64_64 0000000000000004 yyy + 0 $ clang-tot tls.cpp -g -c && llvm-objdump tls.o -r | grep DTP 000000000000002b R_X86_64_DTPOFF64 Unknown $ g++-4.8 tls.cpp -g -c && llvm-objdump tls.o -r | grep DTP 000000000000002a R_X86_64_DTPOFF32 Unknown (yyy was R_X86_64_64 in both GCC and Clang) > > (In reply to comment #0) > > This program fails to link when compiling with debugging info (-g): > > __thread int x; > > int main(){} > > > > It fails with the following message from the linker: > > /usr/bin/aarch64-linux-gnu-ld: /tmp/test2-67df6a.o(.debug_info+0x37): > > R_AARCH64_ABS64 used with TLS symbol x
Ok, it's not clear to me why we are not using R_X86_64_DTPOFF64 on FreeBSD. Should Clang not be using an equivalent relocation on AArch64 (as opposed to R_AARCH64_ABS64)?
(In reply to comment #9) > Ok, it's not clear to me why we are not using R_X86_64_DTPOFF64 on FreeBSD. > > Should Clang not be using an equivalent relocation on AArch64 (as opposed to > R_AARCH64_ABS64)? I don't know anything about FreeBSD, but I imagine it should be - I've not looked at the code in years, though.
(In reply to comment #10) > (In reply to comment #9) > > Ok, it's not clear to me why we are not using R_X86_64_DTPOFF64 on FreeBSD. > > > > Should Clang not be using an equivalent relocation on AArch64 (as opposed to > > R_AARCH64_ABS64)? > > I don't know anything about FreeBSD, but I imagine it should be - I've not > looked at the code in years, though. I'm afraid I may have confused things by discussing two slightly separate, but related issues. The first issue is amd64 FreeBSD not using R_X86_64_DTPOFF64. I believe there should be no difference here (as far as TLS is concerned) between FreeBSD and Linux. The second issue (and the subject of this PR) is AArch64 using an R_AARCH64_ABS64 relocation. This happens on both Linux and FreeBSD, and is what prompts the error from ld.bfd on both OSes.
(In reply to comment #11) > The first issue is amd64 FreeBSD not using R_X86_64_DTPOFF64. I believe > there should be no difference here (as far as TLS is concerned) between > FreeBSD and Linux. That part should be fixed in r231130.
works on trunk with BFD 2.25
(In reply to comment #13) > works on trunk with BFD 2.25 I still see this issue on aarch64 with 3.8 release and ld 2.25 see http://errors.yoctoproject.org/Errors/Details/56334/
I also see this on FreeBSD with Clang 3.8 and ld 2.25.1 FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) test.c produces: 00000000003c 001500000101 R_AARCH64_ABS64 0000000000000000 xxx + 0 00000000005a 001600000101 R_AARCH64_ABS64 0000000000000004 yyy + 0
The original issue isn't fixed. It looks like gcc solves this issue by not adding a DW_AT_location record into DIE for TLS variables when targeting AArch64. Shouldn't we do the same?
Would someone mind describing the consequence of this bug, for those of us that encounter it but don't really know what the warning is trying to tell us. Will the TLS accesses fail, or will there simply be debug information issues?
(In reply to Luke Dalessandro from comment #17) > Would someone mind describing the consequence of this bug, for those of us > that encounter it but don't really know what the warning is trying to tell > us. Will the TLS accesses fail, or will there simply be debug information > issues? No location information will be available for TLS variables.
Fixed by http://llvm.org/viewvc/llvm-project?revision=338655&view=revision.
*** Bug 26998 has been marked as a duplicate of this bug. ***