From: Fangrui Song <maskray@google.com>
To: binutils@sourceware.org
Cc: Fangrui Song <maskray@google.com>
Subject: [PATCH v2] ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg)
Date: Thu, 2 Mar 2023 12:17:22 -0800 [thread overview]
Message-ID: <20230302201722.1304941-1-maskray@google.com> (raw)
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
next reply other threads:[~2023-03-02 20:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 20:17 Fangrui Song [this message]
2023-03-10 9:10 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230302201722.1304941-1-maskray@google.com \
--to=maskray@google.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).