[PATCH v2] ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)

[PATCH v2] ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)

[Fangrui Song]

Similar to
https://sourceware.org/pipermail/binutils/2023-March/126434.html (x86_64).

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

% gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 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_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 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_386_TLS_GD ...`
error which is hard to reason about.

It seems easier to apply this simple change to prevent the footgun.

    PR ld/24784
    * bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.
---
Changes from v1:
* Update description as suggested by Jan (https://sourceware.org/pipermail/binutils/2023-March/126430.html)
---
 bfd/elf32-i386.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bfd/elf32-i386.c b/bfd/elf32-i386.c
index a542029c068..7e6823b40f4 100644
--- a/bfd/elf32-i386.c
+++ b/bfd/elf32-i386.c
@@ -963,7 +963,8 @@ elf_i386_check_tls_transition (asection *sec,
 	  || !((struct elf_x86_link_hash_entry *) h)->tls_get_addr)
 	return false;
       else if (indirect_call)
-	return (ELF32_R_TYPE (rel[1].r_info) == R_386_GOT32X);
+	return (ELF32_R_TYPE (rel[1].r_info) == R_386_GOT32X
+		|| ELF32_R_TYPE (rel[1].r_info) == R_386_GOT32);
       else
 	return (ELF32_R_TYPE (rel[1].r_info) == R_386_PC32
 		|| ELF32_R_TYPE (rel[1].r_info) == R_386_PLT32);
-- 
2.40.0.rc0.216.gc4246ad0f0-goog

Re: [PATCH v2] ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)

[Jan Beulich]

On 02.03.2023 21:17, Fangrui Song via Binutils wrote:
> Similar to
> https://sourceware.org/pipermail/binutils/2023-March/126434.html (x86_64).
> 
> _Thread_local int a;
> int main() { return a; }
> 
> % gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
> /usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 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_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 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_386_TLS_GD ...`
> error which is hard to reason about.
> 
> It seems easier to apply this simple change to prevent the footgun.
> 
>     PR ld/24784
>     * bfd/elf32-i386.c (elf_i386_check_tls_transition): Allow R_386_GOT32.
> ---
> Changes from v1:
> * Update description as suggested by Jan (https://sourceware.org/pipermail/binutils/2023-March/126430.html)

Same here: Okay.

Jan