From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 146D43858D33; Wed, 8 Nov 2023 15:41:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 146D43858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 146D43858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699458116; cv=none; b=IZ7JshWRZBkZaUbBe9u9njmd1q838kYsMsqnYfsGtZHOAiKbivq3U4BbrzkccnLgyL6rQuFzciuxy6HhLvk2U6t8PM0ItVDaChUeO03xCAOt7NH9TDlilL6vVcHHC9s8wa38F/r6Im18YsmrUoocWRgNi+qtJi/ybu8pxA82AyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699458116; c=relaxed/simple; bh=IJoF5fhnqyHPYrGBSkoAOZb6NqnLPTrRvTOAFaR846A=; h=DKIM-Signature:From:Message-Id:Mime-Version:Subject:Date:To; b=x1EhNykClCaadCdJZ4Dtn8LoSwQ/+LJeibVVMOcJzRnwKzrUoQ/bJ+r+t0uW5yR2GlwW/dY6cpdsSzO0ZeWflor6AIlWg2F2MZlDy1J0yvmZY/20gWzKP7ASsWhFmVLOdq3FebfBn05fZVXZbMvl1Sj06Ktrh3+CblsBlW0PG5I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-6bcdfcde944so1832659b3a.1; Wed, 08 Nov 2023 07:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699458113; x=1700062913; darn=gcc.gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=yjqGvVRjMyE9ugZBiaOJKOzsV/19dcgVYqa6oJgxtnM=; b=GAMmu45AM44BNT/EjyffpNCYX5CV4NoVJpJckXMeInIZZd41KSaw2dVvjSvAvWFTzi gH2p8DgeWT7q5luOPboargtxmHIfKXaJJBFxKPd+PwqduOSa9k5t7n7DbRLmfgwyEmkd ixK/DzQvVtvBR+vousf43TKP1fACUJbT5OiHJ2tIkbVICgzcstj2pr08asK1Bmah0DQ8 D/608n+/lZf8MQ2Sq4pdfVyG+BT0RV5jZZsX6HTvlMwfgHyxDSw47JNbdsRR0ymZjb/S P2vaHkZirIxPL1LPYIMb49s5HSv2CFrTCy2AF0giakvol/CtB014GRIpFYmQ7ZhvrTJw 81XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699458113; x=1700062913; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yjqGvVRjMyE9ugZBiaOJKOzsV/19dcgVYqa6oJgxtnM=; b=V2xvlnLddtJZAEcOu34X1lA7fpgoie3GI242Zv0W76k0FEtrS3PB81NyxQH6CPY3dq isLxVJC5TCLlYrogxTm/YNB9uhu76jKOpTD41z283i4Q8NIBPZn/RSa8RHzxa61HJonW VwHZEtFsum9A9pzr0ae0OCTuNwGGgQJbdVUf0te7xe1VH9a3dtJuUER+rxzpJXgyzcL0 z0gqE+3o3nqwJ6viuLxyH1oBZryT3RKDjdK1ZkegDowg2CDeYMNMfcsNzUajNkLQK4cz 460EgyulI80rqkZFqbUgXxjQuWqAUUN+WlZoH1rHb+GrLk5G1dmJ7dL/w6iXIEPbJ8eH L9Kw== X-Gm-Message-State: AOJu0YyuReHDDVMMG6QOj692z7a2QosIw1qDofKNz+lADBSAOob9Q0Z7 T1vc5XSj6hO7P3Z9AOpaGOk= X-Google-Smtp-Source: AGHT+IFFFCGqCC0oaiD5EbUmSlpd0E2Dg7A8n6ivoyMZ20d1HogFckrzlMt6vAM7BaGza70FQaFC8g== X-Received: by 2002:a05:6a00:8904:b0:690:c79c:1912 with SMTP id hw4-20020a056a00890400b00690c79c1912mr2406600pfb.0.1699458112825; Wed, 08 Nov 2023 07:41:52 -0800 (PST) Received: from smtpclient.apple (zz20184013906F627101.userreverse.dion.ne.jp. [111.98.113.1]) by smtp.gmail.com with ESMTPSA id t17-20020a056a00139100b006933866f49dsm9461894pfg.19.2023.11.08.07.41.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2023 07:41:52 -0800 (PST) From: Tatsuyuki Ishi Message-Id: <5E88DEEE-F734-4A81-854D-EF365940700B@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_36EBB211-D53A-45C3-AF80-4E9760B6E984" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold. Date: Thu, 9 Nov 2023 00:41:38 +0900 In-Reply-To: Cc: gcc-patches@gcc.gnu.org, Rui Ueyama , pinskia@gcc.gnu.org, redi@gcc.gnu.org To: Richard Biener References: <20231016050412.9960-1-ishitatsuyuki@gmail.com> <397A5BC2-8A85-4B5D-A21D-F378DF7227EB@gmail.com> <6514036C-81CE-44AA-9C00-F96FF192DAEF@gmail.com> X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --Apple-Mail=_36EBB211-D53A-45C3-AF80-4E9760B6E984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 7, 2023, at 23:37, Richard Biener wrote: >=20 > On Tue, 7 Nov 2023, Tatsuyuki Ishi wrote: >=20 >>> On Oct 16, 2023, at 18:16, Richard Biener wrote: >>>=20 >>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: >>>=20 >>>>=20 >>>>=20 >>>>> On Oct 16, 2023, at 17:55, Richard Biener wrote: >>>>>=20 >>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On Oct 16, 2023, at 17:39, Richard Biener wrote: >>>>>>>=20 >>>>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: >>>>>>>=20 >>>>>>>> lld and mold are platform-agnostic and not prefixed with target tr= iple. >>>>>>>> Prepending the target triple makes it less likely to find the inte= nded >>>>>>>> linker executable. >>>>>>>>=20 >>>>>>>> A potential breaking change is that we no longer try to search for >>>>>>>> triple-prefixed lld/mold binaries anymore. However, since there do= esn't >>>>>>>> seem to be support to build LLVM or mold with triple-prefixed exec= utable >>>>>>>> names, it seems better to just not bother with that case. >>>>>>>>=20 >>>>>>>> PR driver/111605 >>>>>>>>=20 >>>>>>>> gcc/Changelog: >>>>>>>>=20 >>>>>>>> * collect2.cc (main): Do not prepend target triple to >>>>>>>> -fuse-ld=3Dlld,mold. >>>>>>>> --- >>>>>>>> gcc/collect2.cc | 13 ++++++++----- >>>>>>>> 1 file changed, 8 insertions(+), 5 deletions(-) >>>>>>>>=20 >>>>>>>> diff --git a/gcc/collect2.cc b/gcc/collect2.cc >>>>>>>> index 63b9a0c233a..c943f9f577c 100644 >>>>>>>> --- a/gcc/collect2.cc >>>>>>>> +++ b/gcc/collect2.cc >>>>>>>> @@ -865,12 +865,15 @@ main (int argc, char **argv) >>>>>>>> int i; >>>>>>>>=20 >>>>>>>> for (i =3D 0; i < USE_LD_MAX; i++) >>>>>>>> - full_ld_suffixes[i] >>>>>>>> #ifdef CROSS_DIRECTORY_STRUCTURE >>>>>>>> - =3D concat (target_machine, "-", ld_suffixes[i], NULL); >>>>>>>> -#else >>>>>>>> - =3D ld_suffixes[i]; >>>>>>>> -#endif >>>>>>>> + /* lld and mold are platform-agnostic and not prefixed with t= arget >>>>>>>> + triple. */ >>>>>>>> + if (!(i =3D=3D USE_LLD_LD || i =3D=3D USE_MOLD_LD)) >>>>>>>> + full_ld_suffixes[i] =3D concat (target_machine, "-", ld_suf= fixes[i], >>>>>>>> + NULL); >>>>>>>> + else >>>>>>>> +#endif >>>>>>>> + full_ld_suffixes[i] =3D ld_suffixes[i]; >>>>>>>>=20 >>>>>>>> p =3D argv[0] + strlen (argv[0]); >>>>>>>> while (p !=3D argv[0] && !IS_DIR_SEPARATOR (p[-1])) >>>>>>>=20 >>>>>>> Since we later do >>>>>>>=20 >>>>>>> /* Search the compiler directories for `ld'. We have protection ag= ainst >>>>>>> recursive calls in find_a_file. */ >>>>>>> if (ld_file_name =3D=3D 0) >>>>>>> ld_file_name =3D find_a_file (&cpath, ld_suffixes[selected_linker],= =20 >>>>>>> X_OK); >>>>>>> /* Search the ordinary system bin directories >>>>>>> for `ld' (if native linking) or `TARGET-ld' (if cross). */ >>>>>>> if (ld_file_name =3D=3D 0) >>>>>>> ld_file_name =3D find_a_file (&path, full_ld_suffixes[selected_link= er],=20 >>>>>>> X_OK); >>>>>>>=20 >>>>>>> I wonder how having full_ld_suffixes[LLD|MOLD] =3D=3D ld_suffixes[L= LD|MOLD] >>>>>>> fixes anything? >>>>>>=20 >>>>>> Per the linked PR, the intended use case for this is when one wants = to use their system lld/mold with a separately packaged cross toolchain, wi= thout requiring them to symlink their system lld/mold into the cross toolch= ain bin directory. >>>>>>=20 >>>>>> (Note that the first search is against COMPILER_PATH while the latte= r is=20 >>>>>> against PATH). >>>>>=20 >>>>> Ah. So what about instead adding here >>>>>=20 >>>>> /* Search the ordinary system bin directories for mold/lld even in >>>>> a cross configuration. */ >>>>> if (ld_file_name =3D=3D 0 >>>>> && selected_linker =3D=3D ...) >>>>> ld_file_name =3D find_a_file (&path, ld_suffixes[selected_linker], = X_OK); >>>>>=20 >>>>> instead? That would keep things working in case the user has a >>>>> xyz-arch-mold in the system dir but uses GNU ld on the host >>>>> otherwise, lacking a 'mold' binary there? >>>>>=20 >>>>> That is, we'd only add, not change what we search for. >>>>=20 >>>> I considered that, but as described in commit message, it doesn?t seem= anyone has created stuff named xyz-arch-lld or xyz-arch-mold. Closest is G= entoo?s symlink mentioned in this thread, but that?s xyz-arch-ld -> ld.lld/= mold. >>>> As such, this feels like a quirk, not something we need to keep compat= ibility for. >>>=20 >>> I don't have a good idea whether this is the case or not unfortunately >>> so if it's my call I would err on the safe side. >>>=20 >>> We seem to recognize mold and lld only since GCC 12 which both are >>> still maintained so I think we might want to do the change on all >>> those branches? >>>=20 >>> If you feel confident there's indeed no such installs then let's go >>> with your original patch. >>>=20 >>> Thus, OK for trunk and the affected branches after a while of no >>> reported issues. >>=20 >> Hi, >>=20 >> Can I consider this an approval for this patch to be applied to trunk? >=20 > Yes. >=20 >> I would appreciate if this patch could be tested in GCC 14 prereleases. >>=20 >> I suppose backporting after no reported issues in GCC 14 would be the pl= an here? >>=20 >> Please let me know in case of misunderstandings. >=20 > You understood correctly. >=20 > Richard. Hi Richard, I forgot to mention that I don=E2=80=99t have committer / write access. Could you help me get this patch committed? Thanks. Tatsuyuki. >> Thanks, >> Tatsuyuki. >>=20 >>> Thanks, >>> Richard. >>>=20 >>>> The proposed change seems simple enough though, so if you consider thi= s=20 >>>> a compatibility issue I can go for that way as well. >>>=20 >>>> Tatsuyuki. >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Richard. >>>>=20 >>>>=20 >>>=20 >>> --=20 >>> Richard Biener > >>> SUSE Software Solutions Germany GmbH, >>> Frankenstrasse 146, 90461 Nuernberg, Germany; >>> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernbe= rg) >>=20 >>=20 >=20 > --=20 > Richard Biener > > SUSE Software Solutions Germany GmbH, > Frankenstrasse 146, 90461 Nuernberg, Germany; > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) --Apple-Mail=_36EBB211-D53A-45C3-AF80-4E9760B6E984--