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 D1C4F3858D33; Tue, 7 Nov 2023 14:37:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D1C4F3858D33 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 D1C4F3858D33 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=1699367842; cv=none; b=mFCBXToRSPcvvBqNap6zLzPxAq7wM0Ec5xRKHRcrLGCBVadGsMNxOMIVcTvpHUiaafwlsQAos5PmppilyLbJUgTcHv9MITRuJqqOHh8tzo9SvhS6e1Ij0SfBHPRtFu4g/kSfttjgj8buGe0J7Ls2T0kYWs/GRKPn+CifsTVdQbY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699367842; c=relaxed/simple; bh=9Txnz3fLsRuPSHLKOXBHhs5DiRvaP7v2gOgF/LM5smU=; h=DKIM-Signature:DKIM-Signature:Date:From:To:Subject:Message-ID: MIME-Version; b=Hap6y744zN80i+rhc5tDuaIOuiUNyhJQ822dhPTikdBzpTwTCuHKmFU5LuCS7jZ4Y4vPiBYYXI2bQVa/SpkpwkTZlg5YAVI3E0/yn2Hx19SgEYz3GicGd4tdnmb4nus1pj4uI6QxAX+FNWnKEpxAyG6D4Nm4tRHYWZ0sdtXlVpM= 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 12FB71F45A; Tue, 7 Nov 2023 14:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1699367840; 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=ZNtf/n1GFimQwFizDiwtgL0v8flUyYJ7nkaTfLNzgVI=; b=uo39d3Rxp/mbDURJNexwWqfCG11wjZyCWYwjNaWgRoCMELn2fogprGCiTdqJyDZfSoU09s HLJWuuwV9O91g3mC8THTKz4iiccccT4EBdymcqUZqQnPvCm2zf+3szD2jl6lsVh4r8G+MN c/jL9rUfMI3ewyc2ltXfLqnvoeLE4vw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1699367840; 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=ZNtf/n1GFimQwFizDiwtgL0v8flUyYJ7nkaTfLNzgVI=; b=QCUMFkOhG906T1iQAABPTOaiA5h3gkJmUtXqWg9Ah338uCJmwq47gx7jIqJ+17oPa+VOcl Yw7FAeJjt5dKGZDw== 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 CF4EC2C2A3; Tue, 7 Nov 2023 14:37:19 +0000 (UTC) Date: Tue, 7 Nov 2023 14:37:19 +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: 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-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 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. > 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)