From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 93E2F3858D37 for ; Mon, 9 Jan 2023 21:15:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 93E2F3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-x32b.google.com with SMTP id m7-20020a9d73c7000000b00683e2f36c18so5958971otk.0 for ; Mon, 09 Jan 2023 13:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=E2vMcDuO6NgewkkYM6F5VW+rSCP+qZto3671nLlaKxc=; b=mGKTFsJCoympNnddbcPDWXJrCajhB3I9GVbKyyDMheqfcpqifKOerWulRGkujR3JeW M1ag/h6eg0jfTQMjNNG1TUWUj8oc1wikk0mDZMFadcIhDaqd+FHhzI9j3/POp2AbPcpP jk/zC6AvCv/QLdGy/n6ImWxB5lrhqf6Ke5s8rFqI32XgOYa0p2MlDnD9SWy1qwjE/kKj vMdY/I01lICTKo0wJzwomNkkWZysDcyz51W6kOOWO6iNMYerbTl4spp+ztJ/aKuGpfk+ yQCOLj21ebJs1arKmF1jP79wwfRl3uJZcnmSRt8dflS0hEWBdVbDOx0vFk7JfPXIA2w0 4jtg== 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=E2vMcDuO6NgewkkYM6F5VW+rSCP+qZto3671nLlaKxc=; b=GLQRzAMTQ9wBB/mwNprIe9hm4VYYHyyvUHe4QG0UuE7/oBEnvfSsTgH0d2opNBsKoM 6gcG5IMQ6BaGhPIatYcz86bpSYTD7mow8egJ4HSh/2n8jNeUNEAuw8qERP5Uh8tx/1U9 S/sxdY59fnRuEh3NkXTFQrf8C/MZQUvfLLlEMsh/Wb8e8B4rVoryho4NW2Xxlg2KvH32 kpzzrB6xweGCA+98WPIM2VYn/1NifSc101RjKY1HR5N8Xj2WvE+6pCA+kW/IKRts+zqK McBP8IodO+hH4BM4Sb3va2rZ4+iqdx/GVA0XJ489pEXsCgmwzYgdvdJlnydaEfm3plK4 MnYg== X-Gm-Message-State: AFqh2koEZ/A2CRo5QPeVlOWJM7091cvigkfHIdWwvvGOEvH4zW4Nxdj/ U+K9WJ9ZHus6xjNgK379Z2B7AAwz+SS0+NI9r1k= X-Google-Smtp-Source: AMrXdXuRJQ7aohtsgFrYJyPtOo6pkcZzlivwossKmNqxwow/KGfc8EoOLBG4CQvVcueRYcR5X48zq4L5403A5UVijBY= X-Received: by 2002:a05:6830:1c8:b0:66e:b992:749f with SMTP id r8-20020a05683001c800b0066eb992749fmr3708759ota.52.1673298919876; Mon, 09 Jan 2023 13:15:19 -0800 (PST) MIME-Version: 1.0 References: <20230105210542.3573076-1-maskray@google.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 9 Jan 2023 13:14:43 -0800 Message-ID: Subject: Re: [PATCH] ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip) To: Jan Beulich Cc: binutils@sourceware.org, Fangrui Song Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3023.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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 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? > > Jan 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. -- H.J.