From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 248A93858D35; Tue, 7 Nov 2023 14:25:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 248A93858D35 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 248A93858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699367110; cv=none; b=rAQK5d4iAmWkFM9P9vztwYfjXpDi/WeT9EpUJAQJH5bAsCdGEG+KprQI3Rc61fMdMOmE2LqckxF+FN109eN1K6UZzVAmpIj21rHhFHki4ypvZ5Hsayp0RlrnbmNdHEPkHd72sz7ZEPsB0mNQ12uickRydvA3nJAKNGeMJ6Y8D1c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699367110; c=relaxed/simple; bh=iWIX/MIGQi0u2qVVpVHAQSNqJCvoVCJbBjfv9XnY63o=; h=DKIM-Signature:From:Message-Id:Mime-Version:Subject:Date:To; b=X9FEgylZtqN48JBqvg/RWP4IgxmSUouz0dnvwR3qsC9tVylDEXy2yyIm0jTpkg5hddePdO0G8SSa5H+NGpIpaFjlAK6Vee84AhlpEZVc6V/MkfR1z8mNze2GZtP/ncG9UfbXw8bdEVCGApigcaJfrKsBQJsj0ElwnslZUML2qhA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-280c371ff69so877996a91.1; Tue, 07 Nov 2023 06:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699367106; x=1699971906; 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=/amm4Ul22bSc0H9vEbVLsC6vq+CXvOVbNkQ7V/RpiGk=; b=AVKEUjEJNqpQFq2M1Y8IyS5pMOntLf7V7WMBhEkjDG6b2+4Uts3CdqyhhRk705X/Qz lu9Nb4g2PU9OgvRWIIeY6gvc0p4cn7JkZIH/Lqlje4Gq3iX4+qFj2PgDGYJazH4AVnSB wZ4egdl7TFHo11WL6WejDGzBLt3zB6OtK03cQj9PLQRRHEdAP63VBNMBlDpbIynJsTmL T+0z12omHxsaFXpS/gSBHPsaX1PcBLFA0R3H52vqgf5+Pgdcc5Y/khsbilIXzVjFqdo3 FYohIMP12eiCQi45TojD9WL/zTKjzZi+5qhC9jltC6H6tRhSLpQvPBaWOksEWhaCZM0+ qJJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699367106; x=1699971906; 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=/amm4Ul22bSc0H9vEbVLsC6vq+CXvOVbNkQ7V/RpiGk=; b=mMvWaAs4O7jQdpljqRvjG9mnTWts2eL7btxzwtG8P1ky9+2jn631eiA+mT1xpmsTt2 8F7DfjFMYPyJMsR3Ye4p4w0v7efunIEG0y/pvdwJc8aWkzaEx/9Mjnj2XGw8VRJPp2Uu ZCzJOTQ9kv5EGKA49lmJMadVXsMdNSeyVA7xaExyVrUh7Qrf1B3NPQUmS7LG04EEcvaD C1Fzmv8d+Yp1Tg6eRxLAeY0DM4z3nn8fcn48yi9O8acMoKpz83CNlbAN7tPiMl5qrbB4 CmaTPXMMRz5P+FYMqYblTsKTpuP0I3jxDv8nP3+27bmDGyRkFhYiONs1j0z67mHbIHXN xhOQ== X-Gm-Message-State: AOJu0Yyc98hskC9HVpbTuwl1qXR/4uFG9WXNvi9ycRjqpWHxLNslnzlF Y5jPuguweBMrrET9FE4IiFY= X-Google-Smtp-Source: AGHT+IG81En1zbmj4Tp/xgSB8UhlPXv9AkdOxEPiNePFsKaK749cD060IqenEX5KXXy6CaFlarPP0Q== X-Received: by 2002:a17:90a:8402:b0:281:2d56:e751 with SMTP id j2-20020a17090a840200b002812d56e751mr3351920pjn.0.1699367105751; Tue, 07 Nov 2023 06:25:05 -0800 (PST) Received: from smtpclient.apple (zz20184013906F627101.userreverse.dion.ne.jp. [111.98.113.1]) by smtp.gmail.com with ESMTPSA id 24-20020a17090a005800b0027e022bd3e5sm7783186pjb.54.2023.11.07.06.25.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2023 06:25:05 -0800 (PST) From: Tatsuyuki Ishi Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1729ED44-E4A7-4598-8A36-76C5B644D7A5" 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: Tue, 7 Nov 2023 23:24:51 +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.3 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=_1729ED44-E4A7-4598-8A36-76C5B644D7A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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 trip= le. >>>>>> Prepending the target triple makes it less likely to find the intend= ed >>>>>> 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 does= n't >>>>>> seem to be support to build LLVM or mold with triple-prefixed execut= able >>>>>> 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 tar= get >>>>>> + triple. */ >>>>>> + if (!(i =3D=3D USE_LLD_LD || i =3D=3D USE_MOLD_LD)) >>>>>> + full_ld_suffixes[i] =3D concat (target_machine, "-", ld_suffi= xes[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 agai= nst >>>>> 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_linke= r],=20 >>>>> X_OK); >>>>>=20 >>>>> I wonder how having full_ld_suffixes[LLD|MOLD] =3D=3D ld_suffixes[LLD= |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, with= out requiring them to symlink their system lld/mold into the cross toolchai= n bin directory. >>>>=20 >>>> (Note that the first search is against COMPILER_PATH while the latter = 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 a= nyone has created stuff named xyz-arch-lld or xyz-arch-mold. Closest is Gen= too?s symlink mentioned in this thread, but that?s xyz-arch-ld -> ld.lld/mo= ld. >> As such, this feels like a quirk, not something we need to keep compatib= ility 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. Hi, Can I consider this an approval for this patch to be applied to trunk? I would appreciate if this patch could be tested in GCC 14 prereleases. I suppose backporting after no reported issues in GCC 14 would be the plan = here? Please let me know in case of misunderstandings. Thanks, Tatsuyuki. > Thanks, > Richard. >=20 >> The proposed change seems simple enough though, so if you consider this= =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 Nuernberg) --Apple-Mail=_1729ED44-E4A7-4598-8A36-76C5B644D7A5--