R_AARCH64_ABS64 used with TLS symbol

[Quuxplusone]

Bugzilla Link	PR21077
Status	RESOLVED FIXED
Importance	P normal
Reported by	Amanieu d'Antras (amanieu@gmail.com)
Reported on	2014-09-26 08:07:43 -0700
Last modified on	2018-08-01 20:41:44 -0700
Version	trunk
Hardware	PC Linux
CC	anton@korobeynikov.info, dblaikie@gmail.com, echristo@gmail.com, emaste@freebsd.org, ikudrin@accesssoftek.com, kai@redstar.de, kristof.beyls@gmail.com, ldalessandro@gmail.com, Lei.Liu2@windriver.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com, raj.khem@gmail.com, rengolin@gmail.com
Fixed by commit(s)	rL338655
Attachments	gcc.s (1591 bytes, application/octet-stream) clang.s (5530 bytes, application/octet-stream)
Blocks
Blocked by
See also	PR26998

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

[Quuxplusone]

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

[Quuxplusone]

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.

[Quuxplusone]

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?

[Quuxplusone]

Attached gcc.s (1591 bytes, application/octet-stream): Assembly generated by GCC

[Quuxplusone]

Attached clang.s (5530 bytes, application/octet-stream): Assembly generated by Clang

[Quuxplusone]

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.

[Quuxplusone]

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

[Quuxplusone]

(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

[Quuxplusone]

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)?

[Quuxplusone]

(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.

[Quuxplusone]

(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.

[Quuxplusone]

(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.

[Quuxplusone]

works on trunk with BFD 2.25

[Quuxplusone]

(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/

[Quuxplusone]

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

[Quuxplusone]

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?

[Quuxplusone]

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?

[Quuxplusone]

(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.

[Quuxplusone]

Fixed by http://llvm.org/viewvc/llvm-project?revision=338655&view=revision.

[Quuxplusone]

_Bug 26998 has been marked as a duplicate of this bug._