From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) by sourceware.org (Postfix) with ESMTPS id 099093858418; Mon, 16 Oct 2023 08:59:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 099093858418 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 099093858418 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::530 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697446777; cv=none; b=uoexHq+YPW5+ygrGUUq3q6VYgy/kb3ZAF9H9km869XurwyiLOh11YOm36guT30wvIEJ2hktc2Akn4jqOSh2BndLMQc/zXJ2hewDBgA7k9oRIrHU67UMQjGRvvWaY0w2McFfmTam5lGBnNtf3gbzHxqEc1AefMW6wKFrUg4sSL+4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697446777; c=relaxed/simple; bh=aRBmu02+MIyolU5TLu/de/JoVMNrGuefj+jUWmovPR4=; h=DKIM-Signature:From:Message-Id:Mime-Version:Subject:Date:To; b=hc/9LyZPWpQFdTQgyMOvt9bMhy7yv89jm61B73K5H4o6Se9rgsTWYTLFBaRsq+v+xbL5lNbqAKxjuw9bN28qaE72yfI7dR78X9ehUQOvY62sZGn7XPO2ORFL00YyJvAXL2GtKoOHGwBTOs5PI9FkE8jPqdmDswKiqU4hcFu2kJk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-55b5a37acb6so619499a12.0; Mon, 16 Oct 2023 01:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697446774; x=1698051574; 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=91u5ARlNkORWCfqf+V7kInZ519Agl9YgPGCkgxJsWKo=; b=I6DqknMKcvshDh81fqH7jc6YkQN79NClPaDZULoOW9/jRYoorKDPvAlD1gP+3F//3c /8lTRwjuqoG1SmBnWiC0yFJlP0NWzGyX1mbkBZSSnp5r1c6m8dtgrBn9ZUC3UEkoLlrv lTNGM7ow7sY2HI0XJ3kBz3TuOe8Loj6v76vR8dGOZhYrnQnCbYSKjoYFueYvPPwxRY6+ Bp9JuFeFMwsLttOBhCkqIFVzfyXGHoZTN0tkbluh/3KoUNjwq2IdmJAazb81xIEvboO4 sH4RIw+9AIcIMHaZQBYx2sG1BB7IihK0fzjHiHH7HCftqQevhIqZC5DRl6KvN9LuOoY6 TOZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697446774; x=1698051574; 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=91u5ARlNkORWCfqf+V7kInZ519Agl9YgPGCkgxJsWKo=; b=wKaoibdPlPeQU5mnIFmOPNbpcy7dNc3JtdCnHfbakpkbbeFit9wCj4NbLHfxFtg77l JLsQ7B8S2I3jQyR1z6sppJn2foGNiHZbnnK8apvOJTAw/EgJLnDDXPwDWEbh4rBgtEYb uQNlHb12kXu6Vl79qlmy+Mn5rtMPjnjksAKKueljrfRerjUMwY3M0TImzWbU71k8BYmL RyTNIejPTA03H/PUpcoFvXCltCsx/B9I2Fl1K3rbCTRmpsglbnZ//XGxXzWMRaeyXWnU vXDWixX+XI7JhabGl9GJt61gqp+lFoGR6TbDzBrKlYOWQDwtxN3o6yvWKOtY9xw78pbh Hjwg== X-Gm-Message-State: AOJu0YwoF1wQqOSvAiozT9YrKkAs1iXRakAd0ZdWCw0u41l/5flE/z+N 9SXq9xEVN5Ej7Grh8cxYInFjBF6BIdZ1iV+o X-Google-Smtp-Source: AGHT+IGwSTU3FUfwR8akQN8U98TvOJqq1z5a5Cnijq299J6gqox09B0qraCibreDiKZPS8nN2/3nnw== X-Received: by 2002:a17:903:2306:b0:1bb:ac37:384b with SMTP id d6-20020a170903230600b001bbac37384bmr37843979plh.6.1697446773854; Mon, 16 Oct 2023 01:59:33 -0700 (PDT) Received: from smtpclient.apple (zz20184013906F627101.userreverse.dion.ne.jp. [111.98.113.1]) by smtp.gmail.com with ESMTPSA id a16-20020a170902ecd000b001c72d5e16acsm2711910plh.57.2023.10.16.01.59.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2023 01:59:33 -0700 (PDT) From: Tatsuyuki Ishi Message-Id: <6514036C-81CE-44AA-9C00-F96FF192DAEF@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_500235D1-7810-4AE9-95EB-B91010348653" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\)) Subject: Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold. Date: Mon, 16 Oct 2023 17:59:20 +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> X-Mailer: Apple Mail (2.3774.100.2.1.4) 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 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=_500235D1-7810-4AE9-95EB-B91010348653 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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 triple. >>>> Prepending the target triple makes it less likely to find the intended >>>> 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 doesn't >>>> seem to be support to build LLVM or mold with triple-prefixed executab= le >>>> 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 target >>>> + triple. */ >>>> + if (!(i =3D=3D USE_LLD_LD || i =3D=3D USE_MOLD_LD)) >>>> + full_ld_suffixes[i] =3D concat (target_machine, "-", ld_suffixe= s[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 against >>> 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_linker= ],=20 >>> X_OK); >>>=20 >>> I wonder how having full_ld_suffixes[LLD|MOLD] =3D=3D ld_suffixes[LLD|M= OLD] >>> fixes anything? >>=20 >> Per the linked PR, the intended use case for this is when one wants to u= se their system lld/mold with a separately packaged cross toolchain, withou= t requiring them to symlink their system lld/mold into the cross toolchain = 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. I considered that, but as described in commit message, it doesn=E2=80=99t s= eem anyone has created stuff named xyz-arch-lld or xyz-arch-mold. Closest i= s Gentoo=E2=80=99s symlink mentioned in this thread, but that=E2=80=99s xyz= -arch-ld -> ld.lld/mold. As such, this feels like a quirk, not something we need to keep compatibili= ty for. The proposed change seems simple enough though, so if you consider this a c= ompatibility issue I can go for that way as well. Tatsuyuki. >=20 > Thanks, > Richard. --Apple-Mail=_500235D1-7810-4AE9-95EB-B91010348653--