From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1149.google.com (mail-yw1-x1149.google.com [IPv6:2607:f8b0:4864:20::1149]) by sourceware.org (Postfix) with ESMTPS id 880033858D37 for ; Thu, 2 Mar 2023 20:17:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 880033858D37 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=flex--maskray.bounces.google.com Received: by mail-yw1-x1149.google.com with SMTP id 00721157ae682-538116920c3so1486747b3.15 for ; Thu, 02 Mar 2023 12:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=dKq4kasEm7pgp39nK5cLwHDvLZgIYucbAlknr1fzuXc=; b=SNi0sYA2jOeq9nY8mXicfFtsaZ9252uJFsqBjPS0HZcsxX43SyMXwmsYQ9PPX7aZ6j aE5M0476iwZZFl3uS3b2GT1GvW2CQ7v9rNsVJ/gWBu2lnGNyZUWpj0m/6Upfk5X9hrb1 4sX2r5d/YYbV2DAqB5qY0VDZP6IL6rE/msjQjAv3uf/VuAf/eO2CeUPfay+2tC1hYOsg x8qeYxxfKuhFfE21xgAEL8xMG91cIxc9dwuz69oONHXGOY7xlY+A7Axr0t1+nKlb1UOZ e2MNYdDlon/mcm84/Rn+84KBIje6FAOBUwtyt+pcAIdwbRAjBwxjiyiPQsSELO8AlAOz 8bcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dKq4kasEm7pgp39nK5cLwHDvLZgIYucbAlknr1fzuXc=; b=7UU1WGNXfux9yFeDLGrgtm5sZh5OwrG9mAHVTGmiHGxpv0HpQezvVeZRM93cl5lM66 fvkVupJjHP1Wm+aoEsq4RMHtvWFPPyQgVuKquk6adgKwDyd+gqH2BMUcXlV/DKKD7e4b Jzd5RXh9nKnclHG3znNW/TLW/vB6/uFyxf6iHFPfu5qII3pTcKFcNAmnj6gs9XSLSjXX iliFI/QTOxHjBCzGuW3vj9jyTZYPKAHOeO95BmYuYMWiLr6bCohf5uUfhTUOSB81dey6 OI9xpvAJMtEbAbUPZIB7o/h6Y8Li3YoPbWOMeidch5FHYttXm9i7or+PV9+ye472sFU0 mXxA== X-Gm-Message-State: AO0yUKUpuri8ASqayLXriJxyO3GpETqr+fEd0EzlMvjPZg5pTIY+vjzN eLXK7FRCyaFgYm8SqUMNLMk4W0x+NT8kLz3y0txZjflw4mZzmvx5DILT1AhHYYSRCHawJLfzKiz XFVrIfHEegTsPCIsWh0NzXOcqWL5pRTeeWlnnk98D+CQTwjOaq5bRSdRhVBW1EVhVrw== X-Google-Smtp-Source: AK7set+Z4c8qP7NQ/cLlACQWPo7E09zkzRTRSP+g29A6W1xK5R/EejHgxU7AM3BrZ2DXGBaDyv3UHL7EzW/H X-Received: from maskray.svl.corp.google.com ([2620:15c:2d3:205:2ccc:cda:c135:351d]) (user=maskray job=sendgmr) by 2002:a81:9443:0:b0:539:5618:427 with SMTP id l64-20020a819443000000b0053956180427mr25ywg.275.1677788246360; Thu, 02 Mar 2023 12:17:26 -0800 (PST) Date: Thu, 2 Mar 2023 12:17:22 -0800 Mime-Version: 1.0 Message-ID: <20230302201722.1304941-1-maskray@google.com> Subject: [PATCH v2] ld: Allow R_386_GOT32 for call *__tls_get_addr@GOT(%reg) From: Fangrui Song To: binutils@sourceware.org Cc: Fangrui Song Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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