From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id DE0A93858D39 for ; Fri, 6 Jan 2023 23:02:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE0A93858D39 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-pf1-x435.google.com with SMTP id p123so1181652pfb.8 for ; Fri, 06 Jan 2023 15:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MK30MBTLlURM9E2P2Qpp3fBBOtUeyrXslDyu6coliho=; b=dXKDrgO838bJHU9DHp/rVEofRdKQSazKSTuYGp4ySY28d1/0Ziawr5JCIBJvDrlxXe F9VKadDtXSDap2NOvxnVvVhS276doyVr6d0Jjf3+JpMzo4N1VwmKzCTOO48aN+EM4L8Z OQOjaMe7sPqH021etBS4dUzpu2LRPxbSVMitZgfGOEslYQBh8Em6HOZvdGV1yvNmnMCS pLh3Pk2VEqCClt9mdAk9jlBUrsshFDTPBeIyZzSIkY0GS80TDSmKy2idTjzGsbvBvxcy Z0TZeUDdXHvdcYMBjUr7v92dAZl62wlJRY5TehdqpBHUWNjSiEUef7UC8dxuoAJA9S6T zOnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MK30MBTLlURM9E2P2Qpp3fBBOtUeyrXslDyu6coliho=; b=qsLmIX+xHrabDfvtdm7hMTWjPyLz0Hmu+zKvn6LefZmdB085q3TNYElw0FBMCNA36f +EpD2nr0rMrOAuV+mI8ojcySQU7twNo85WXtdsyLHWDTjH8DedENRJsj+RfDNVJIDH2n 17htFQ1kLQX2C4P3H0NUMOQGWB+F2gXYFVP2cPv7px++Hn8K9DQSE3svN2Ns0FjkbsvT wC1zr75D3DlUOxCIlD7yA0JIkMLAagwJ1LdRw4ImOuGqCvCynvkEiih5EaCg7ufIkM5N TcmM81c9BoD/YOl+/ai69Uo+xvwC4JyoPzXowA/Y/lipvl53+qv63+WDgyC+sYvPXiOq kQUg== X-Gm-Message-State: AFqh2kqaAOzOtmwsV5U7IP4rDwZ+qiUich+BZp04hKKZYa68ni5SxX6j zi/Bcjq3+hzuU3DMD+osUYW0KthPjDbDOr6HE6TTcx+stCeYnZNS X-Google-Smtp-Source: AMrXdXvYBts+WzZF5MY60gmBrI2/DXVdVftI6ZcF0tFH2WGAwyLql0vZ7IuXegnT+SYFzcoz9aPKnGrAjX/lJ9vCpzo= X-Received: by 2002:a05:6a00:368e:b0:584:26b2:a7af with SMTP id dw14-20020a056a00368e00b0058426b2a7afmr233146pfb.53.1673046132589; Fri, 06 Jan 2023 15:02:12 -0800 (PST) MIME-Version: 1.0 References: <20230105210542.3573076-1-maskray@google.com> In-Reply-To: From: Fangrui Song Date: Fri, 6 Jan 2023 15:02:00 -0800 Message-ID: Subject: Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip) To: "H.J. Lu" Cc: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-23.5 required=5.0 tests=BAYES_00,BODY_8BITS,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 Fri, Jan 6, 2023 at 2:42 PM H.J. Lu wrote: > > On Fri, Jan 6, 2023 at 1:44 PM Fangrui Song wrote: > > > > On Fri, Jan 6, 2023 at 1:27 PM H.J. Lu wrote: > > > > > > On Fri, Jan 6, 2023 at 1:25 PM Fangrui Song wrot= e: > > > > > > > > On Fri, Jan 6, 2023 at 1:14 PM H.J. Lu wrote= : > > > > > > > > > > On Fri, Jan 6, 2023 at 10:48 AM Fangrui Song = wrote: > > > > > > > > > > > > On Fri, Jan 6, 2023 at 9:04 AM H.J. Lu wr= ote: > > > > > > > > > > > > > > On Thu, Jan 5, 2023 at 1:06 PM Fangrui Song via Binutils > > > > > > > wrote: > > > > > > > > > > > > > > > > _Thread_local int a; > > > > > > > > int main() { return a; } > > > > > > > > > > > > > > > > % gcc -fno-plt -fpic a.c -fuse-ld=3Dbfd -Wa,-mrelax-relocat= ions=3Dno > > > > > > > > /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 v= alue > > > > > > > > collect2: error: ld returned 1 exit status > > > > > > > > > > > > > > > > This commit fixes the issue. > > > > > > > > > > > > > > > > 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 =3D=3D R_X86_64_PLTOFF64; > > > > > > > > else if (indirect_call) > > > > > > > > - return r_type =3D=3D R_X86_64_GOTPCRELX; > > > > > > > > + return (r_type =3D=3D R_X86_64_GOTPCRELX || r_t= ype =3D=3D R_X86_64_GOTPCREL); > > > > > > > > else > > > > > > > > return (r_type =3D=3D R_X86_64_PC32 || r_type = =3D=3D R_X86_64_PLT32); > > > > > > > > } > > > > > > > > -- > > > > > > > > 2.39.0.314.g84b9a713c41-goog > > > > > > > > > > > > > > > > > > > > > > Since the new TLS sequence was added after R_X86_64_GOTPCRELX= was > > > > > > > required for call, R_X86_64_GOTPCREL should be invalid in thi= s TLS sequence. > > > > > > > > > > > > > > -- > > > > > > > H.J. > > > > > > > > > > > > I have multiple arguments (albeit no single one is very strong)= that > > > > > > this 1-deletion-1-addition change provides benefits for users (= IMHO > > > > > > with no burden to binutils at all). > > > > > > > > > > > > Some projects may add -Wa,-mrelax-relocations=3Dno to work arou= nd older > > > > > > GNU ld. Then the project's toolchain requirement may increase a= nd no > > > > > > longer need to work around older GNU ld. > > > > > > But a distribution may for some reason use a global -fno-plt (e= .g. > > > > > > Arch Linux) and then run into this TLS GD/LD->IE/LE optimizatio= n > > > > > > issue. > > > > > > > > > > > > rust src/ci/docker/host-x86_64/*musl/Dockerfile > > > > > > openjdk/jdk19u make/autoconf/flags-cflags.m4 (this file appears= to be > > > > > > copied into quite a few projects) > > > > > > Linux kernel arch/x86/boot/compressed/Makefile (not a good exam= ple as > > > > > > it doesn't use TLS AFAICT) > > > > > > > > > > > > R_X86_64_GOTPCREL isn't purely usefull. It may help linker desi= gn: for > > > > > > R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX, the linker can make = a > > > > > > decision upfront whether a GOT entry is needed > > > > > > (this affects the size of .got, which may affect section layout= and > > > > > > whether other relocations may overflow). > > > > > > This may increase risk of 32-bit relocation overflow. > > > > > > R_X86_64_GOTPCREL can mitigate the risk while being aware to th= e user. > > > > > > > > > > > > rustc somehow disables x86 relaxed relocations and defaults to = `-Z > > > > > > > > > > Why is that? > > > > > > > > It's assuredly a rust's problem and I am trying to fix that in > > > > https://github.com/rust-lang/rust/pull/106511 > > > > > > > > The -Wa,-mrelax-relocations=3Dno problem may affect more packages. > > > > > > -mrelax-relocations=3Dno should be a workaround for the older linker.= It > > > shouldn't be used with the current linker. > > > > A project may choose to work with many linker versions. > > For simplicity, before it decides to drop compatibility with GNU > > ld<2.26 (AIUI GOTPCRELX was supported in 2.26), > > it may unconditionally add -Wa,-mrelax-relocations=3Dno, instead of > > -mrelax-relocations=3Dno is only supported with the newer binutils. The relocatable object file producer and the consumer may be on different machines and use different binutils versions. https://github.com/rust-lang/rust/commit/305aca86f9d8d132650b495f610f9abe52= 39fec6 added -Wa,-mrelax-relocations=3Dno so that the relocatable object files can be used on a user machine with an old ld. https://github.com/IHaskell/IHaskell/issues/636 and https://github.com/dcos/dcos/commit/facda25019e07051f501b39720b4e71049bd003= 0 likely use the same argument. In other cases, the project may use -Wa,-mrelax-relocations=3Dno with Clang (where they assume a not-too-old version), but need to work with system ld (which may be old). > > doing configure work to check linker support. > > The TLS sequence from -fno-plt doesn't work for the older linker. > The older linker support should be dropped for -fno-plt. > > > Now a user may use -fno-plt (Arch Linux, rustc, maybe Alpine) and run > > into the aforementioned TLS problem. > > > > This 1-deletion-1-addition change can address this issue with no > > maintenance burden on binutils side in my opinion, > > so I made this patch. > > > > The linker design I described is true as well. Whether GOTPCRELX leads > > to a GOT entry can be decided at relocation scanning time, before the > > section layout is decided. > > Users may make a conscious decision to use GOTPCREL to avoid potential > > relocation overflow risk. > > > > GOTPCREL isn't really dead. It can be used with Intel LAM and tagged > > global variables (with non-zero high address bits) > > https://reviews.llvm.org/D111343 > > GOTPCREL instead of GOTPCRELX makes it clear an instruction > > referencing the variable isn't supposed to be relaxed. > > The address of the local symbol, foo, in > > movq foo@GOTPCREL(%rip), %rax > > is assigned by the linker. I am not sure how the tag is involved here. > Besides, it is the call instruction here. This is an auxiliary argument. I wanted to emphasize that GOTPCREL isn't dead and did not intend to use it with this call instruction. If GOTPCRELX is used and the distance between the current location and the symbol is larger than 2**31, this will trigger a relocation overflow. This happens with tagged globals with non-zero high address bits. A linker can fix the problem by avoiding relaxation, increasing the size of .got . This requires that it scans relocations more than once. If GOTPCRELX is decided upfront whether it needs relaxation or not, on an arch which doesn't use range extension thunks like x86, technically relocations can just be scanned once. > > > > > > plt=3Dno` and now relies on llvm-project to work around the GNU= ld > > > > > > compatibility issue. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > =E5=AE=8B=E6=96=B9=E7=9D=BF > > > > > > > > > > > > > > > > > > > > -- > > > > > H.J. > > > > > > > > > > > > > > > > -- > > > > =E5=AE=8B=E6=96=B9=E7=9D=BF > > > > > > > > > > > > -- > > > H.J. > > > > > > > > -- > > =E5=AE=8B=E6=96=B9=E7=9D=BF > > > > -- > H.J. --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF