From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 168E1386180B; Thu, 9 Nov 2023 13:06:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 168E1386180B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 168E1386180B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:67c:2178:6::1c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699535213; cv=none; b=TZabWlFXNRdDK041xFJLa3XYCe94cBav0vh4p6PXbO1Pn1+n8hoDKcVkRldl38JY+TeSGriRLjUptG6maY+eNac03/d4Nud5SYoVxAjNjse8LJG9491T+7owSiVizFte9y3w6xq4hAKGQrUO/YMwIgjAHaXSky3Z9LKntXbLahY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699535213; c=relaxed/simple; bh=6ANsGbAoVm3/gp4MZkmbwX+VhbvZtPtusbUpXvia8K0=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=ST18fBHp8NImydB16Fjgi66ktgUi0BBHqld3J2zEiBovOeUwE4+86QgvHF6t5XvVXTqOA05RsKlarpGT8VKRpqQgtZtRsB2j/aX3uabzUA26tLf3x23xYYizucCMOFYtMFAU3DjSNV2pXhE+AwsCCdZkoSU5EJoHhK5QkffIhP0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 1962521986; Thu, 9 Nov 2023 13:06:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1699535209; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=crZ9QNK7pGf2DQSKplEipL2ZdOO2pzKdQso+mFE+5pc=; b=oeFwJJrFV+slKjzVKpy1+F3uEOQaum2oeHf5oHHZ4y+NcWuF+b+qbPAnWvW1TpRr2EdQxA 4dUFl9OKK89Mulu9N0YE8qHEkxUOkDv5dFqoJSb6mE/o3KmwyPbxVAPEdAyGhLNIP/q6mv CCzHb4yxPWwcW6OiIn1uexQmNUq367M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1699535209; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=crZ9QNK7pGf2DQSKplEipL2ZdOO2pzKdQso+mFE+5pc=; b=rssEq3uubWNq3IDf0EwMKirGpQ92F325hV7F77mbapUuRjA+9Ag5nN7ZolGc24tt+rNoTJ Q56hF/lrD3NtBdCQ== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id DF4722C676; Thu, 9 Nov 2023 13:06:48 +0000 (UTC) Date: Thu, 9 Nov 2023 13:06:48 +0000 (UTC) From: Richard Biener To: Tatsuyuki Ishi cc: gcc-patches@gcc.gnu.org, Rui Ueyama , pinskia@gcc.gnu.org, redi@gcc.gnu.org Subject: Re: [PATCH] Do not prepend target triple to -fuse-ld=lld,mold. In-Reply-To: <5E88DEEE-F734-4A81-854D-EF365940700B@gmail.com> Message-ID: References: <20231016050412.9960-1-ishitatsuyuki@gmail.com> <397A5BC2-8A85-4B5D-A21D-F378DF7227EB@gmail.com> <6514036C-81CE-44AA-9C00-F96FF192DAEF@gmail.com> <5E88DEEE-F734-4A81-854D-EF365940700B@gmail.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: On Thu, 9 Nov 2023, Tatsuyuki Ishi wrote: > > On Nov 7, 2023, at 23:37, Richard Biener wrote: > > > > On Tue, 7 Nov 2023, Tatsuyuki Ishi wrote: > > > >>> On Oct 16, 2023, at 18:16, Richard Biener wrote: > >>> > >>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: > >>> > >>>> > >>>> > >>>>> On Oct 16, 2023, at 17:55, Richard Biener wrote: > >>>>> > >>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>>> On Oct 16, 2023, at 17:39, Richard Biener wrote: > >>>>>>> > >>>>>>> On Mon, 16 Oct 2023, Tatsuyuki Ishi wrote: > >>>>>>> > >>>>>>>> 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. > >>>>>>>> > >>>>>>>> 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 executable > >>>>>>>> names, it seems better to just not bother with that case. > >>>>>>>> > >>>>>>>> PR driver/111605 > >>>>>>>> > >>>>>>>> gcc/Changelog: > >>>>>>>> > >>>>>>>> * collect2.cc (main): Do not prepend target triple to > >>>>>>>> -fuse-ld=lld,mold. > >>>>>>>> --- > >>>>>>>> gcc/collect2.cc | 13 ++++++++----- > >>>>>>>> 1 file changed, 8 insertions(+), 5 deletions(-) > >>>>>>>> > >>>>>>>> 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; > >>>>>>>> > >>>>>>>> for (i = 0; i < USE_LD_MAX; i++) > >>>>>>>> - full_ld_suffixes[i] > >>>>>>>> #ifdef CROSS_DIRECTORY_STRUCTURE > >>>>>>>> - = concat (target_machine, "-", ld_suffixes[i], NULL); > >>>>>>>> -#else > >>>>>>>> - = ld_suffixes[i]; > >>>>>>>> -#endif > >>>>>>>> + /* lld and mold are platform-agnostic and not prefixed with target > >>>>>>>> + triple. */ > >>>>>>>> + if (!(i == USE_LLD_LD || i == USE_MOLD_LD)) > >>>>>>>> + full_ld_suffixes[i] = concat (target_machine, "-", ld_suffixes[i], > >>>>>>>> + NULL); > >>>>>>>> + else > >>>>>>>> +#endif > >>>>>>>> + full_ld_suffixes[i] = ld_suffixes[i]; > >>>>>>>> > >>>>>>>> p = argv[0] + strlen (argv[0]); > >>>>>>>> while (p != argv[0] && !IS_DIR_SEPARATOR (p[-1])) > >>>>>>> > >>>>>>> Since we later do > >>>>>>> > >>>>>>> /* Search the compiler directories for `ld'. We have protection against > >>>>>>> recursive calls in find_a_file. */ > >>>>>>> if (ld_file_name == 0) > >>>>>>> ld_file_name = find_a_file (&cpath, ld_suffixes[selected_linker], > >>>>>>> X_OK); > >>>>>>> /* Search the ordinary system bin directories > >>>>>>> for `ld' (if native linking) or `TARGET-ld' (if cross). */ > >>>>>>> if (ld_file_name == 0) > >>>>>>> ld_file_name = find_a_file (&path, full_ld_suffixes[selected_linker], > >>>>>>> X_OK); > >>>>>>> > >>>>>>> I wonder how having full_ld_suffixes[LLD|MOLD] == ld_suffixes[LLD|MOLD] > >>>>>>> fixes anything? > >>>>>> > >>>>>> 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, without requiring them to symlink their system lld/mold into the cross toolchain bin directory. > >>>>>> > >>>>>> (Note that the first search is against COMPILER_PATH while the latter is > >>>>>> against PATH). > >>>>> > >>>>> Ah. So what about instead adding here > >>>>> > >>>>> /* Search the ordinary system bin directories for mold/lld even in > >>>>> a cross configuration. */ > >>>>> if (ld_file_name == 0 > >>>>> && selected_linker == ...) > >>>>> ld_file_name = find_a_file (&path, ld_suffixes[selected_linker], X_OK); > >>>>> > >>>>> 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? > >>>>> > >>>>> That is, we'd only add, not change what we search for. > >>>> > >>>> 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 Gentoo?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 compatibility for. > >>> > >>> 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. > >>> > >>> 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? > >>> > >>> If you feel confident there's indeed no such installs then let's go > >>> with your original patch. > >>> > >>> 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? > > > > Yes. > > > >> 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. > > > > You understood correctly. > > > > Richard. > > Hi Richard, > > I forgot to mention that I don?t have committer / write access. > > Could you help me get this patch committed? Thanks. I pushed it to trunk sofar. Richard. > > Tatsuyuki. > > >> Thanks, > >> Tatsuyuki. > >> > >>> Thanks, > >>> Richard. > >>> > >>>> The proposed change seems simple enough though, so if you consider this > >>>> a compatibility issue I can go for that way as well. > >>> > >>>> Tatsuyuki. > >>>> > >>>>> > >>>>> Thanks, > >>>>> Richard. > >>>> > >>>> > >>> > >>> -- > >>> Richard Biener > > >>> SUSE Software Solutions Germany GmbH, > >>> Frankenstrasse 146, 90461 Nuernberg, Germany; > >>> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) > >> > >> > > > > -- > > Richard Biener > > > SUSE Software Solutions Germany GmbH, > > Frankenstrasse 146, 90461 Nuernberg, Germany; > > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)