[PATCH v2] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)

[Fangrui Song <maskray@google.com>]

On 2023-03-02, Jan Beulich wrote:
>On 05.01.2023 22:05, Fangrui Song via Binutils wrote:
>> _Thread_local int a;
>> int main() { return a; }
>>
>> % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
>> /usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
>> /usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
>> collect2: error: ld returned 1 exit status
>>
>> This commit fixes the issue.
>
>The discussion with H.J. looks to have died out, without a clear result.
>May I suggest the following (also for the other, 32-bit patch): You
>extend the description to address H.J.'s concerns verbally, and unless
>he comes forward pointing actual flaws in here, I'd then intend to
>approve the changes.
>
>Jan
>
>>     PR ld/24784
>>     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
>>       R_X86_64_GOTPCREL.
>> ---
>>  bfd/elf64-x86-64.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
>> index 914f82d0151..095fe2e0fe6 100644
>> --- a/bfd/elf64-x86-64.c
>> +++ b/bfd/elf64-x86-64.c
>> @@ -1241,7 +1241,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
>>  	  if (largepic)
>>  	    return r_type == R_X86_64_PLTOFF64;
>>  	  else if (indirect_call)
>> -	    return r_type == R_X86_64_GOTPCRELX;
>> +	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
>>  	  else
>>  	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
>>  	}
>

Thank you!  Here is PATCH v2 with an updated description but no code
change:


 From a8df373aec097dcdabe46717dd95cdd9b16ef7d7 Mon Sep 17 00:00:00 2001
From: Fangrui Song <maskray@google.com>
Date: Thu, 5 Jan 2023 12:45:27 -0800
Subject: [PATCH v2] ld: Allow R_X86_64_GOTPCREL for call
  *__tls_get_addr@GOTPCREL(%rip)

_Thread_local int a;
int main() { return a; }

% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

This commit fixes the issue.

There is an argument that the -fno-plt TLS sequence was added after
R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
intended to be unsupported.

Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today).  Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
error which is hard to reason about.

There is another argument which may be weaker but relevant to the
necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
likely need some assembler support to disable relaxation.  Without the
support and if the compiler needs to support many gas versions, the
simplest solutation would be to use -Wa,-mrelax-relocations=no.

     PR ld/24784
     * bfd/elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
       R_X86_64_GOTPCREL.
---
  bfd/elf64-x86-64.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index 0aa9af5d8fc..dd987ee011b 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -1253,7 +1253,7 @@ elf_x86_64_check_tls_transition (bfd *abfd,
  	  if (largepic)
  	    return r_type == R_X86_64_PLTOFF64;
  	  else if (indirect_call)
-	    return r_type == R_X86_64_GOTPCRELX;
+	    return (r_type == R_X86_64_GOTPCRELX || r_type == R_X86_64_GOTPCREL);
  	  else
  	    return (r_type == R_X86_64_PC32 || r_type == R_X86_64_PLT32);
  	}
-- 
2.40.0.rc0.216.gc4246ad0f0-goog