From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 4F4E43858C2A; Mon, 16 Oct 2023 09:16:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4F4E43858C2A 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 4F4E43858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.220.29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697447812; cv=none; b=Vn6hZdUNnor6HuTgzryMtfijX5GO8Ict/hRXXDSYUeabKAoF4rYe2zZJdmzNV4Z0pXdu0P5hHBboX+jX+/vxgu6lLv1jw9WbWu4oEgdJHVK2ungk8f9dHPX2pRI5JYFJ74muo+jI6FRlCKNVCqJgG8lBG58Rs+ZHanXtD8wen6k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697447812; c=relaxed/simple; bh=LmJ0T01O+bUEzH01LB+9TJ/k/lMzQdlayJVMUFhcD/I=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=MmBpliH63sQkgM2Q5zwwUQ2OlFX/lMyqSbXwqEYXwXXbK0pZXizHyuLwAg/sa1T6swxZQzwc5AF6IPlDps4hWIcl2x2wyXCJLzWPVzkQxciYBi7QR9e8mG6OOHn9h+p4T/q1o5pZyuO8v+jNPdb7GFI4ZkeOyMjiOw9Ia2wFzRg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 6C3391FDB2; Mon, 16 Oct 2023 09:16:48 +0000 (UTC) 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 2AA3E2D18C; Mon, 16 Oct 2023 09:16:48 +0000 (UTC) Date: Mon, 16 Oct 2023 09:16: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: <6514036C-81CE-44AA-9C00-F96FF192DAEF@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> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: Authentication-Results: smtp-out2.suse.de; none X-Rspamd-Server: rspamd2 X-Spamd-Result: default: False [-4.00 / 50.00]; REPLY(-4.00)[] X-Spam-Score: -4.00 X-Rspamd-Queue-Id: 6C3391FDB2 X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,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, 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. 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)