From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 2AD3A383236B for ; Tue, 10 Jan 2023 21:02:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2AD3A383236B 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-x433.google.com with SMTP id c26so5409172pfp.10 for ; Tue, 10 Jan 2023 13:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xu3mwURRJKLAdxjwWGHkxlRBUHhsLRkHD+UtMjkvo64=; b=jdzuoTAIpYt6HQN1s2m3eXlQ2IvQR7ll+duwn4DKRWpAGoSVuynIrclM2MeTylC+3d NSKHjSUVkyO7QL5Oe9c8UWAytnvEa6Dg8FgqPBmhD3ApJoNEkpIVk0n974juhhBorU/R 3xvGfvzkK5Zs9dvhd9XK4KXjZ3T1FsoeJral2QWaRCFV8HHXum5dPIndy8KTgIfuOrjQ ldJqGFgH8UGIcYR/hlM1KgZ5AjHLMfWGJTuSWdTCoF49h5RjL9vGrwumlzu/hsmdS7eo qEIZQ8BAv2X5ImKDK8P6I/WE0DFBc3rH23XkFMuq2uvRjhfbr1ngYvo06AqOCtBwiTz2 cK4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=xu3mwURRJKLAdxjwWGHkxlRBUHhsLRkHD+UtMjkvo64=; b=yP/8qWDrSp1ecxx1ohKDSnnt/ILgzv8LSYDvcfCza5+bZiBJNK5S7lK+HHYWDY9qZb LJEiJj/xWUbEMoIcIAGR087Wpc6dG7U6RPVCul2Z00c3j6d4g/ZOsZnLKlIWDhwKoHj3 g/38X7LngVEPS6yU9JGl8utUYIQQf8biIF+ERVXGQFX6dJRa+5dh+UNM5pwGDYq24ubr je/04IQ83v6srX/ilJZS6SDh7VSV+et6LC0NUtucNWUxZTVjz2xknK4zz2mcv70T82M7 urkDETUwn/qNSKBh5G7rcS514t/AeSASnvwEoGw1femhs22aYNLu/XMjCvdMmqAciVG/ Actg== X-Gm-Message-State: AFqh2kqqE7iufsHD4Tb0cn5pwu93kssZgCZsRYpLQOW45JRGhZehMx4m Dp/uy2xh9ygC/LRJY9HHZU2IPXB3moENPXiDcJv4sX1igyC+2e8y X-Google-Smtp-Source: AMrXdXsq3yJHwp3W7hJCZSvzt/NZ9H5wxF3jHsUP82PG6V/bNKi/4s4IY/kamDQ3hvknaO5q6ED2O1f7IHybUp8rZfw= X-Received: by 2002:a63:4503:0:b0:499:7f08:40c3 with SMTP id s3-20020a634503000000b004997f0840c3mr4436923pga.80.1673384540790; Tue, 10 Jan 2023 13:02:20 -0800 (PST) MIME-Version: 1.0 References: <20230105210542.3573076-1-maskray@google.com> <0c9cd182-ce08-6720-1e51-d7171f075641@suse.com> In-Reply-To: From: Fangrui Song Date: Tue, 10 Jan 2023 13:02:08 -0800 Message-ID: Subject: Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip) To: "H.J. Lu" Cc: Jan Beulich , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-24.8 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 Tue, Jan 10, 2023 at 12:40 PM H.J. Lu wrote: > > On Tue, Jan 10, 2023 at 1:16 AM Jan Beulich wrote: > > > > On 09.01.2023 22:14, H.J. Lu wrote: > > > On Mon, Jan 9, 2023 at 12:15 AM Jan Beulich wrote: > > >> > > >> On 06.01.2023 18:03, H.J. Lu via Binutils wrote: > > >>> 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=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. > > >>>> > > >>>> 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); > > >>>> } > > >>>> -- > > >>>> 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 this TLS sequence. > > >> > > >> While this may well be, would you mind pointing out (more to Fangrui than to > > >> me) what bad his proposed change would do? > > > > > > The problem is caused by the combination of -fno-plt and > > > -Wa,-mrelax-relocations=no. > > > -Wa,-mrelax-relocations=no was added to generate object files to be > > > consumed by the > > > older linkers. On the other hand, -fno-plt requires newer linkers. > > > As the result, > > > -fno-plt -Wa,-mrelax-relocations=no generates object files which > > > aren't compatible > > > with neither older linkers nor newer linkers. > > > -Wa,-mrelax-relocations shouldn't be used > > > together with -fno-plt. > > > > Imo use of such option combinations should either be disallowed (warned > > about at the very least) or produce sensible output. I guess only the > > latter would help Fangrui ... > > > > This isn't a supported combination. I believe -Wa,-mrelax-relocations=no > should be removed. > > -- > H.J. Removing -Wa,-mrelax-relocations=no implies that R_X86_64_GOTPCREL is completely useless and -Wl,--no-relax is not useful for x86. As my earliest replies mentioned, a relocation type indication no relaxation is useful in some cases: hwasan (Intel LAM) references to global variables, one-pass relocation scanning design in a linker, even if we disregard the relocatable-file-producer with old-linker-consumer compatibility scenarios. If the linker can decide upfront whether GOTPCREL{,X} needs a GOT entry, the relocation scanning pass be one-pass and be completely moved before synthetic sections (.got, .plt, .got.plt, etc), instead of interleaving relocation scanning, synthetic section size decision, and section layout.