From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id E7A733858D33 for ; Thu, 2 Mar 2023 20:10:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E7A733858D33 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com Received: by mail-pj1-x1031.google.com with SMTP id ce8-20020a17090aff0800b0023a61cff2c6so749609pjb.0 for ; Thu, 02 Mar 2023 12:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4UopmjilIWUezm4YsHqH4Z6Kn4k3vo91KKxuoBhgTQU=; b=dLbRJAUT5HJgCyBX76zTuKL6FoKK+csCeMSpCFP/F3ku7YFx7J/+zKcbyYAd6NGywJ s1PbSb+tzvbDmey76F3yKL4q+IBcVOQKR/5JdcqMwp0Q/7KZXjHhYd7hj/H4Ny9g+qf9 HLjyndnYwiSMCQ4d6LpHtVHrbSFXT6aaFI4R6gl076MuTtfdl9vIPJD0MMyZAgQAyNYR N/kEY6yd2OsXz6Fkcg5QAAqO9wv0exmc/XnSDKlVgqKi6U4blzvd8OCZXS3YMqrLbeEp +Posgw2GEmU02Lu/2TqCj8VAH35WlHrg7TuThM4PnFndruobj1BZDlMQL80AWhQm817z Cz6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4UopmjilIWUezm4YsHqH4Z6Kn4k3vo91KKxuoBhgTQU=; b=xg2KztkGeggTkEXeiNIQ9tNCKin6DN66x5vBDMP5z/3GuGBLZNe5jqIFBvoVX/YeEq kcEKF8S8LBUJWXb/6hO61LqyFGKsjr+ikDMh93Z+0p7rGzVzO3xKpNwHFHKA5PCIuzUM b1jrMspSE8WrTjBwZbjduc1+7w7WDsemLHzxtZO6oERDB9BsRIEeQ11LTeAyigUhpbAZ S7rBrnP1GpnnjyiO7+OLQGaC0ywB6UuYVt+7T1PGWI3/PMoBUILrnNXv/563pQAR7ini V1jTMfobSJSipUp1HwOxYaICC//LRuX9wa+kzsfcCNbHhfv/brV3jUBKBYGXxlOcp1Iu BZ/A== X-Gm-Message-State: AO0yUKU2kInuhChiO78oBghTwsz/HM8gY6Hkcyj56eOmxPLOh/ni7e8x UEzE4HgCqjnPBl23smRB61N7mQ== X-Google-Smtp-Source: AK7set9gXRVDTVNSH2XQYArD5Q0r4whpoa/S/XOEPNYnFLlJKNRFVT+hR6U2BaylC2AzBKN9WffKZw== X-Received: by 2002:a17:903:1390:b0:19e:6b08:578c with SMTP id jx16-20020a170903139000b0019e6b08578cmr27560plb.1.1677787832635; Thu, 02 Mar 2023 12:10:32 -0800 (PST) Received: from google.com ([2620:15c:2d3:205:2ccc:cda:c135:351d]) by smtp.gmail.com with ESMTPSA id k25-20020a63ba19000000b004facdf070d6sm76034pgf.39.2023.03.02.12.10.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Mar 2023 12:10:32 -0800 (PST) Date: Thu, 2 Mar 2023 12:10:29 -0800 From: Fangrui Song To: Jan Beulich Cc: binutils@sourceware.org, "H.J. Lu" Subject: [PATCH v2] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip) Message-ID: <20230302201029.vflqmyjxh7qnyxa3@google.com> References: <20230105210542.3573076-1-maskray@google.com> <2c693059-fcc0-0874-68be-47bbfef47260@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <2c693059-fcc0-0874-68be-47bbfef47260@suse.com> X-Spam-Status: No, score=-27.4 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_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: 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 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