From nobody Mon Jul 19 09:57:11 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AF1412A664C for ; Mon, 19 Jul 2021 09:57:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GSy1l0JLSz3pn4 for ; Mon, 19 Jul 2021 09:57:15 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id E0C3A2E2D0 for ; Mon, 19 Jul 2021 09:57:14 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-191-32-244.range86-191.btcentralplus.com [86.191.32.244]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 7A19D2AE1F for ; Mon, 19 Jul 2021 10:57:13 +0100 (BST) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) To: toolchain@freebsd.org References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> From: David Chisnall Message-ID: <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> Date: Mon, 19 Jul 2021 10:57:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 In-Reply-To: <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 16/07/2021 12:15, Mark Millard via freebsd-toolchain wrote: > As far as I know the /usr/bin/clang++ related FreeBSD > toolchain never has a file aarch64-unknown-freebsd14.0-ld > in FreeBSD. (And similarly fr other suffices than ld.) There is nothing FreeBSD-specific in this behaviour in clang. If someone wanted to provide a different search behaviour for the clang in the base system then that would be possible, but in general I am strongly opposed to any special casing of behaviour in the system compiler. It's already incredibly annoying that the system compiler doesn't search /usr/local/include and /usr/local/lib so everything I build on FreeBSD needs to be explicitly told 'yes please do actually search the place where the system installed libraries, thanks'. > In other words, why is aarch64-unknown-freebsd14.0-ld > even listed in TargetSpecificExecutables for the system > toolchain's clang++ ? It isn't. It is part of the generic search logic. The search logic says, when compiling for {target triple}, prefer {target triple}-{tool name} over {tool name}. When the clang driver looks for ld, it looks for > I would argue that the default FreeBSD system toolchain > configuration/operation should be adjusted/patched to not > have automatic defaults that cause parts of that toolchain > to not be used even though they are present, just because > some unrelated/independent port(s) have been installed that > are a different toolchain. (Explicitly enabling/allowing > alternate matches may well be reasonable.) The only way of doing this would be to completely remove all search logic and hard-code the paths. > > As far as I know, there is no guarantee of compatibility > with the gcc/g++/gnu related toolchain, with the error > message that I reported being an example for attempted > -flto use. -flto requires LLD. You can force that with -fuse-ld=lld. Clang then will only find things called [{target triple}-]ld.lld >> See the Driver::GetProgramPath() function: >> https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Driver.cpp#L4981 > It looks like if there was an implcit/automatic -B /usr/bin > when /usr/bin/clang++ is the native FreeBSD toolchain one, > that the problem would be avoided. > > But, as, stands, that has to be done explicitly on the > command lines in order to tell clang++ to use its own > related FreeBSD toolchain instead of using one from > ports. But then we'd have a divergence between the system compiler and clang installed any other way. It is expected behaviour that if I install a tool prefixed by the target triple then it will be used in preference to the system one. >> Note that the native binutils package does not cause these problems, >> since it prefixes its tools with $arch-portbld-freebsd14.0. E.g., the >> 'vendor' field of the triple is set to "portbld", not "unknown". >> >> I guess the flavored binutils packages do use the "unknown" vendor field >> to avoid installation conflicts. But at some point this should be >> resolved: either all binutils ports should use the "portbld" vendor, or >> all of them should use "unknown", but this mixing is causing trouble, in >> my opinion. > It has been all portbld at times in the past. That mix is also a > problem. 3 distinct naming structures are needed, not just 2, in > order to prevent mixing from occurring without some form of > explicit request for a mix. Setting the default target triple in the base system compiler to use freebsd as the vendor would avoid this problem: Unless you explicitly install something as {arch}-freebsd-freebsd[version]-{tool} then the base system clang won't use it. David From nobody Mon Jul 19 12:35:21 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D216127E0AB for ; Mon, 19 Jul 2021 12:35:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GT1XH0947z4jtw for ; Mon, 19 Jul 2021 12:35:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626698124; bh=qouXfMz6KYuOXq9DdIBWpynrrAHDz4yWWtKUNjDjLp0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=d87NASU6W4szuKWnqysD2Hvnk2wWou1F5o87PXHtA5lU8QLp55+hHkyFZ3pgGbu5lNAdNJmw+4K2sRyYyVvXycnwJtWVAWZJ48E3Cp/BQxCIee6Hsn9gRfPwdF1HfznUGpnEd9F8VIlYO1Unm1T2QU776WKoGRQ4RKZlmOWefXAn/nHlDsrtY06BGFCJu94CBD3BN4bx2n3ql2yOHfmYd5n1ISv2QKysLBh9saZoQYOtQmNu8692+lkNQCKEbTPQPwop1/FXW5Zd4NCaIbrK2L/nWCiUvZAzvvmR7LSiZJUWNYkDVjQ72GddNjHBLaTic6ovjBBiQPEX4eXzw245WQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626698124; bh=62mhLQheeAHA6Qk0vBdivyT/6bVRg16QVT2loWHX/JF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ddRQDI+tX+yTecc/i/qLFxSWuplNt+uAC5O9i29zK6lHG4MfcZj/EkUfsWT/aDikT84ZFOMB6MkOKzORTgCZZ5DcIYG46PdfMzkuTQcfqOfSrw6su3p6x6DLuuWJzC3WSUcxUmDisKbxhx5BxMiad8P5BNwUyfEyWjGFFnRGjGIHsIyGfSagRVRroVm/hmy4ZbRMQft7S0jdld3MpSq5m39umgj1w83iFEB3cCJO0JvK7a0FwPxOJShCvwRkkfCpf6AV5xH+BwLnGWrvhlpzqlyBhy6UAgtnuAiITMt3GK1oAjuEaC0i9May3AhApROk6APtpy83Z/Zju2MAZ5P2BA== X-YMail-OSG: 54dNl9QVM1mejRL7APMGy4t5Lxxt6qEuS1icCnIU2rroMrASOegXKwBqRdbn71h B_4X0yUL1h5eoZNz5Ydn0mS5hIT74OEcvCaIQmQT0HITiamJChC3x9PYxXX2FxElmaP7i026bGBd D5eA1Bsvahbz_xaCe3LZaUzvkRpr8GeKVJisPfCGGoAaJ1AqJs8nGhO_7U82DSxRpUnO2WJfVtie RFsOY6Db.hTp0d_Wx.D8XzFacvS0_XTXXBoYVw4Wu4rarvEuywaXvd9aL5clRaV2Km9d5vsCbaVL .uvuC8IQZLlaHQoY3HeJv4OpkYrAvzs6diyVy9E2m22Wfn89tfvuhDKb14FcA3.HG2vc5L.eeHl7 UCkKUGPBE.pJwFIKDS7i38houFW6bYVPc3iclxjTJ8AbP4qoVBKVQFcWkGdFoAgRFpZYv.daGdIY AhgX_P.xjvwQcErfeRggIVkfHFr2cdned1Q4jitr9gBKjp0BgDb0ZduEE9alEy5C3Gttur1kIM5K 52_lF_0.C8YCichC1oamiVzijMzgr90ZSaWBI8eiq8bR0e8s3bpuuFY06asEsimOgRgEemczl.3r VneJXZ8Nk_b9smkNeLoL3hiprSOxiXFjCgFfZYNqd_7mGY9yovgJZWU9tkIvuv27Ki7yThXYjJ1R cZ9yBdtM9rZYvHft.Canbn2ftPVoH_6N2v2u2.0Jlfj.KabvQL6coZr.3faEj6QWNtaemvD6Yqcw YQPZ0BcQN.QmcKh5bxfDx_gAsrcjO2cfKULU4vRyTSSF3cek4lviBkopBpQPnn8Aq_eLzKXidDse SS8yPONEcVNzLSMNQXENGHmy6u2SgkbWZoA9BhzjRYVYYxjECLj1MsgAyAVR.PnZEkTAhJsV8iMl 0ZkTHfIVToDcELl1vovtOmDxQdMD2NAiBE.YzA8WSOvSSUVDz9KdUWuoF0ShX5GD8yqP7V8NtFCd Etb4QkBMyf6t527.E6OgldMhza2g6VVCcRYoL45uWD0Zu4koN.m70b8F4hJsD1C9W7TYIalVAmy1 CQNiDycAY6HsrSioCliJvwjSaQ_HDVWNGYRb0xsUbVHypoHjFZzk8cWOtXUfOXwuzggIby35.7OK 2iCLczRPLmItAI.FhuRI9tZyZijtua65Xdq5oWkECp8t80XR7rmke_VUerfxKkTzDSfN4UYh86ei YeeFZRlmPjW77NgQzqODB4OlMbvTz2VUf6zAVn_XWGJajaPeXJjIDsPZoILVpvNuzZy9a0K5CC0K NwmEzN9j43UpeiJveuMP9iUUTuG.T.588ONl6wB1FKPZ.QpSqJpyIVyPXnFOKkEm3Q0j4_rXHQ9t aXrBlWRfvYISWJoWBBcHqGMn_URjVCZkg77Z0E.OPKCPQTn_BQZnMLmyeGmpByX.7OCgriPCJlFN 16HqrkBXGLamoPH7MSTok8p2MKtsxzykJ7iWPUXkmtLUuuwXC4SHCcvvIQpStjkJx_s_luyB9bb. LYp4iWCB_1ZqgA5EdwsG6BCkKdrLxLzPuPSs204G1bc_sDf301X3Gz02pkXI_272ChbQwtYOJ9Wc kb2vU_P102cnc905Gyh8cJ8Xuq.OXBThrmiicwiAkHldMbt2ZUcHKC_YPuv1RWfxbUzOkifsEcHh .sgJo.uFGuRstCb8i14I3QU627O.rW2mw8TjFROucgGnMOeF2k9TuHSqnGR14mFOeCi_m_Q7D8pp .Kk7e54rhhdl2pYMWERtnuZvR6JFB_GUwJNtScJkkCBYqIs2KJ873iJfIPF6lvXACSA51p6CDJ8f 4I1VG9a97yf4bwjfwnpfgl.mTv61lt4UrnX4KCEBIyzuyJ6Cc.5JMfkLMgAQlztE2bFuk_bxSYMt YLtltL0VAdEcXPOaJOAdSbWvkKeoLeoEvRBKp94NdsFOfvnBzK7S4Dyix1B9_7JO6fxFxPTVEPl2 q_Qjfd6_LLzZ9lDvhvTM97RcRE2LziOy.dLHuaByRkzvkuv0ogHveKzDIJLnGiq29ZZngq13DTM_ WYxGOjb3OEWxZVvVbkpHse.T_FrB9_7SOGz9IuuN5cesKIBiL0ME74bEY9uRogcS1ldWhNCosZ0T fJEnBpoGCb8ZrfJ13JvV4.a9FTPcJlPwPQAR2d7kwOEP4q.Lobj_gSVIt.UYDeECjdbK_wNQW1ZR VlWZowtWdwC7plUuPBgpMDjvDD2BORRvoK59GRdR_iCU0m2_hAX.MN2CMyIKSU973KSnQVvD.7pI QjdyWhZ.hdkLnwi0sCmkJXLxP3WcZx7hB8IRk5g7RH2nk3Cc7aFuR17gSZ3EYG970IfNgzt.B1Xl aCLEreiilZ3hWWohZ9XfZ8L7gesGBbt3brpY_iJT0dJRfKgOPd.fM2cg4clJIEsZONlqThPNuS0o zULC6yJlilNv4JmNwx3YWybX4fsHF_p2IZPxEYZgnluM8o2KbZXOdNuKUtBCPGkKDEEhPevnMgbo geu_43TrJhg_fuUdWspQ_sxYsn7385Lf3XKoha1em8j5flLb3KKtYlqXO0ORPNxQC5HkRMzsQi_W dwET4Fr6gCcJGgAgu7TgyhBb7GO7mSpc1szFI2pfW91h_UbJtV1ZZArto8H1u7r8c X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Jul 2021 12:35:24 +0000 Received: by kubenode512.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9c839c813e69c08c885ec105ab4989c2; Mon, 19 Jul 2021 12:35:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) In-Reply-To: <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> Date: Mon, 19 Jul 2021 05:35:21 -0700 Cc: toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GT1XH0947z4jtw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-19, at 02:57, David Chisnall = wrote: > On 16/07/2021 12:15, Mark Millard via freebsd-toolchain wrote: >> As far as I know the /usr/bin/clang++ related FreeBSD >> toolchain never has a file aarch64-unknown-freebsd14.0-ld >> in FreeBSD. (And similarly fr other suffices than ld.) >=20 > There is nothing FreeBSD-specific in this behaviour in clang. If = someone wanted to provide a different search behaviour for the clang in = the base system then that would be possible, but in general I am = strongly opposed to any special casing of behaviour in the system = compiler. It's already incredibly annoying that the system compiler = doesn't search /usr/local/include and /usr/local/lib so everything I = build on FreeBSD needs to be explicitly told 'yes please do actually = search the place where the system installed libraries, thanks'. = https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html#Directory-Option= s reports that gcc does not look in those places with file name prefixes for cpp, cc1, or ld. It makes no mention of looking based on a prefix ending in text analogous to: aarch64-unknown-freebsd14.0- So there are no words about such names having priority either. And gcc uses /usr/lib/gcc/ and /usr/local/lib/gcc/ in preference to using PATH entries as prefixes, stopping on the first match found. (This and other wording support later comments about a fairly common industry practice.) >> In other words, why is aarch64-unknown-freebsd14.0-ld >> even listed in TargetSpecificExecutables for the system >> toolchain's clang++ ? >=20 > It isn't. It is part of the generic search logic. The search logic = says, when compiling for {target triple}, prefer {target triple}-{tool = name} over {tool name}. When the clang driver looks for ld, it looks = for gcc is not documented to do automatically do such that I've found. >> I would argue that the default FreeBSD system toolchain >> configuration/operation should be adjusted/patched to not >> have automatic defaults that cause parts of that toolchain >> to not be used even though they are present, just because >> some unrelated/independent port(s) have been installed that >> are a different toolchain. (Explicitly enabling/allowing >> alternate matches may well be reasonable.) >=20 > The only way of doing this would be to completely remove all search = logic and hard-code the paths. See the likes of what gcc is documented to do for an example from the industry that need not match files from other tool chains because the search starts with special places for the specific toolchain and accepts matches found in those places in preference to other places. >> As far as I know, there is no guarantee of compatibility >> with the gcc/g++/gnu related toolchain, with the error >> message that I reported being an example for attempted >> -flto use. >=20 > -flto requires LLD. You can force that with -fuse-ld=3Dlld. Clang = then will only find things called [{target triple}-]ld.lld If I specify -flto (which I did), why is the command invalid by definition (produces an error message) and so require more command line options to correct the behavior to not get an error? Why should the installation or removal of a incompatible tool chain change the status of the system's clang++ command line? (The message is far from an obvious one as well, complaining about a missing file path.) There is another message from me where I note that I'd figured out the -fuse-ld=3Dlld hack, although I omitted "ld." in the example: should have been aarch64-unknown-freebsd14.0-ld.lld . I'm actively using this technique because it seems to have the minimal other potential consequences. >>> See the Driver::GetProgramPath() function: >>> = https://github.com/llvm/llvm-project/blob/release/12.x/clang/lib/Driver/Dr= iver.cpp#L4981 >> It looks like if there was an implcit/automatic -B /usr/bin >> when /usr/bin/clang++ is the native FreeBSD toolchain one, >> that the problem would be avoided. >> But, as, stands, that has to be done explicitly on the >> command lines in order to tell clang++ to use its own >> related FreeBSD toolchain instead of using one from >> ports. >=20 > But then we'd have a divergence between the system compiler and clang = installed any other way. It is expected behaviour that if I install a = tool prefixed by the target triple then it will be used in preference to = the system one. In the industry, it is fairly normal for a tool chain to have a place unique to it that wins unless something special is specified. (And that is after lots of variations have been tried over the decades.) I've tried to illustrate that with gcc but it is just one point and I do not claim there is universal following of such. >>> Note that the native binutils package does not cause these problems, >>> since it prefixes its tools with $arch-portbld-freebsd14.0. E.g., = the >>> 'vendor' field of the triple is set to "portbld", not "unknown". >>>=20 >>> I guess the flavored binutils packages do use the "unknown" vendor = field >>> to avoid installation conflicts. But at some point this should be >>> resolved: either all binutils ports should use the "portbld" vendor, = or >>> all of them should use "unknown", but this mixing is causing = trouble, in >>> my opinion. >> It has been all portbld at times in the past. That mix is also a >> problem. 3 distinct naming structures are needed, not just 2, in >> order to prevent mixing from occurring without some form of >> explicit request for a mix. >=20 > Setting the default target triple in the base system compiler to use = freebsd as the vendor would avoid this problem: Unless you explicitly = install something as {arch}-freebsd-freebsd[version]-{tool} then the = base system clang won't use it. Yep, relative to this matching of files issue anyway. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Jul 19 14:40:56 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F4FE1270059 for ; Mon, 19 Jul 2021 14:41:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GT4K835tzz3MqD for ; Mon, 19 Jul 2021 14:41:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4BDC11711 for ; Mon, 19 Jul 2021 14:41:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-191-32-244.range86-191.btcentralplus.com [86.191.32.244]) by smtp.theravensnest.org (Postfix) with ESMTPSA id C36872AE28 for ; Mon, 19 Jul 2021 15:40:58 +0100 (BST) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) To: toolchain@freebsd.org References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> From: David Chisnall Message-ID: Date: Mon, 19 Jul 2021 15:40:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 19/07/2021 13:35, Mark Millard via toolchain wrote: > gcc is not documented to do automatically do such that I've > found. GCC is not Clang. GCC does not allow dynamically choosing the target. If you want a GCC that targets aarch64-unknown-freebsd, then you must build a copy of GCC that targets that triple. If you want a version of clang that targets aarch64-unknown-freebsd, then you pass that to the -target argument. The clang driver will provide a *default* value for the -target argument if one is not provided. >> -flto requires LLD. You can force that with -fuse-ld=lld. Clang then will only find things called [{target triple}-]ld.lld > If I specify -flto (which I did), why is the command invalid > by definition (produces an error message) and so require more > command line options to correct the behavior to not get an > error? Why should the installation or removal of a incompatible > tool chain change the status of the system's clang++ command > line? Clang does not know if ld is lld. It expects that the linker that you provide is compatible with the linker arguments that you provide. If lld is installed as {target}-ld, or if no {target}-ld exists and lld is installed as {somewhere on the search path}/ld, then it will work. If the linker installed on the search path is BFD or some other mostly compatible ld, then it will work unless -flto is or some other linker flag that is not compatible with that linker is specified. I am aware of at least three other non-lld linkers that do support LTO with LLVM, clang doesn't know, for all possible linkers you might have installed, which ones support which flags. > > (The message is far from an obvious one as well, complaining > about a missing file path.) Note that this error comes from your linker, not clang. It is a bit odd that the base system clang tries to use the gold plugin but we don't install it. It should probably check for the existence of LLVMgold.so and not pass it to the linker if it doesn't exist. > There is another message from me where I note that I'd figured > out the -fuse-ld=lld hack, although I omitted "ld." in the > example: should have been aarch64-unknown-freebsd14.0-ld.lld . > I'm actively using this technique because it seems to have the > minimal other potential consequences. If you do anything that depends on a specific linker or linker behaviour (e.g. LTO) then specifying the linker to use is good practice, not a 'hack'. > In the industry, it is fairly normal for a tool chain to > have a place unique to it that wins unless something > special is specified. (And that is after lots of > variations have been tried over the decades.) I've tried > to illustrate that with gcc but it is just one point and > I do not claim there is universal following of such. It is also normal in the industry for a toolchain to be non-modular and to support a single target. Both of these were considered anti-features by LLVM. David From nobody Mon Jul 19 17:00:13 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 70AC83EE5CE for ; Mon, 19 Jul 2021 17:00:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GT7Pz0rRGz4X4r for ; Mon, 19 Jul 2021 17:00:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626714021; bh=K54vfuT1MLcnbnTIUNihi1vg0IPi+/90tTsu4Nv3N5A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HWMFtvFRu7kfyAbMPWJjU7dpFpM7Dhj8KR/1Rx19vAMjW0He8QnUimbN89dSkipSjIQfcsrBtry112/mhl6GtGPr0nFQfGMdBCaq+gKvWaGyVs6ne6LD+krwQQjmDRaqNeDreb5jSuLIvHCY0PKm7GV0UmkDcT8EGH2CWVPCBtb5TSJfjmUeTrseYt/pmL6htXjGv1y4Mzs4r0wqjG23WVJVAjVAXdHD32qxJefqa6ObJ8AtsvToEUW3s1wJiaUEWa/1XZ2fsiIv591LQDtimfqqB/MW4K0vJrt5NC9DVPpq8BqzA9E2wx3F3L8Vuz+cDdIgONcR5ZY/Ao3J7bogag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626714021; bh=srRNGkZmGbyFEci01ICKF/bdJ4eidD3iyyDtua04ale=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Ip26P41COL1nVIVCl9NYO/wjYXxzmJjO4LgUzRUpCAKNkL37FrIsw1IM9GsuG/DMq1Xz5YwkzVcnQ4iogo4rZfzvbThwFCGoFgFjhy3pL1PPlpNkyH31wm8g1FmEWJ0S0SCg2UM/8wPg9JpuluuWIW4rMl+55g5xNi5hZeih01/lFtxKPIIcOj1WFLyMYSXyUNTRIERwDUc37hFc5hB+iQIrdDF9CjKxDZJHljiPM0HvmM7QE58IgmpFG3cUeQXighaRMyiTS9H5pMV3gpUrfzSQFYNnlWIuEAwe1yDOx0mapzjyUfFm6ZAi/Ifol5XezW6Epe7CZJHbcAzkGneNtw== X-YMail-OSG: klhO8UYVM1lhMSlCaVQy1YOmHTX6Yr5slMVQAoHqsuSjDJTv2zF5VWdjNkOjf3X zccKQtL4F7Qm_N8343Hn76OQviuq7oLJwi1OkS17Mu6ZH1gSgd6r5Neezrmg99N7ZVHSY7BD2k0r MkTLtUJH8xFDAqDT11Rda3qpbk4_gS9dzbubncbcbdzTb1y2RkfyBU.OfpVff_Lhp3TOGZ5aw7am __RHVGkrD8eMBkHKlF.Ydi0hESixceLUralJiodg62.qF8_T08lx4D67nG7cmrckpmqEovDTkb2X aY6026CFu_h65Au9E4oglc05wto47l7X1K7gLBZ_yptoOOrPiqpzcu_eDTtYUoPskbq65pW1oBPf 7vJk0gBryBhgXAWd0jnGYNawlKo8WMhH3mw_eyO4vpDLr54vaYR2FJK6BQHVTRyW_Tjlnw_PjZ8T Xny3G_Rfebf739iiR7p1SeXUSltgScIA64Kbacmtfggjfn50FIID_2Fa_D7CIhsqB4ciR313FIVU MmNiYFsFvA.wtshruyqcSNWw6NbeD4h1e5pmnD9HejApvJrXnNHjNq3LGaK2z_FmEALn48pr8vy2 qOFI10dGItYPArsjlFz4gnwKsfPB48Baqe.XIs.3I5T0J6GlR64kzNJe3LD.154nQreJrF16CLgP HQltObJD5C9pEf1hi_Gn1W2ZK0K1M0ECxBzD.gzxxorDsiw8x17wR99b2yQcljgP_8.wwijlcuVe mHeJrn9.N7QCtRgHNIMRTPXw4EsTLNDfcuRePCHRrSFXZkUHvqT87_jJ3BNpzU.GCIvi8GIFZ4X0 tgPPm2myPjzcmZ48cuHi_D.oybj.BabeSd7elUP88x8XOd94mqSQHaFjqWuYpzaHpeHt4FX3z3.M KSTIrthXGpCxH.VsQboHbV9JH_skqzgGw4FH5tigK4S2IJxsH0MNBO710EsM72sqXi2ls.kd_05y Z3wHZbcNI_c3pBkvm_XK32NqufD_5ctiBGg20F_fNQDf8h.HSiSUX5g3X62SHcnj0LITmE6ZlS6y jT7JcEB0qO6vzfPfMILG6rmLXtTegDq3iFa43enjuxoYzZrK4F66ZkOKIPeupFQXlefmeW01kQ7h EK52Qdm7unYaNHng1UVePup1CO5ZosseNpAnq0N7Rkp5uzzA3Pw1Z4u.T6gSW1DGRoYQDzvHZU59 8wL6AgkWRggw7iqjKwycMseXSPGbqAOqnQM5h.TSfAIX2EiUWGysPvQ_wWxasBlYcj.FB9sRbEeP 4nQCUOKMT0jCXgjrGRHsnSTE2DU6HUoRB25ajmAXAtpBZlqsuGVNjig4EKcPFAcMtarySZC7S_Xc pCroU8S7rSYv5LqugaqaIXaahxpKpr.7DZfOg7uxskUpP_mAty3BSvA3jiTJS.FeuYqOOQM.u6Ja AHPD_QRAKW9uFfHBT67AqaccSHd9hfBoh6NHADdyTtWZ0y0JL6WMLCHWPq_G9qSDxiSASHOosG05 1Vmx._IKqs1cApdV.Sqc4aQVMbpjgCMvnTICHeOz5QnnDydsZOn6C_BNiApcjtGbd.tJLBipFzEb ltvGjPdsLfQ8ruEeytjSM3ikLirOzo9S4WkbVUVcoRsvMnBXpxJdLUvIEF7NKCEQ96CiMOv41hJa Sw9DZqLDNYXPoAZ4k.Xs_07IWi6siUB_qnJLTPXLh.Kp4h9CXPWqqyIU0t.GcpnrTL7jcOC7sXS1 w1bcnR9._AJvyNG2g5ihTL09xRry3h3EdtBWhxUuugPagSoIrCajv3HcT3pVeRoP4z05js8dLjbR nrYc04n0RzmE3kucJRlBsiGnx3.ovShdKRuIcZ9AI5ZP1Vnt.WUfA0XttCI752V2kQrjr146Igsa GNMKp_p3MmThZd_2BxxffmhrU.piqSPpbig2blY7ucdSI0ieMIN2j98Yznu01pee72XWbYuM9QR3 DZfAZVdaI5HEaD3FtYUpYvoK090pSGvAuJ7V4hip47L_t.8STLOmJhBinM1GKtUvU6eKuIza0aGA BLfNq9j10gQ3KVNEwfyPuJIIJ6.nD9ACUM9aKnzUJV3pez142IxuC7RKygomDxqqNEX3kMxev4BH 2wpWNEh7dvCuw7gUjEQlBAxb55crR2AjHi0nspmQyAzPT5cclfvlBciMLQibKwJRO8lh89Ezk0h1 VZ3SN0u50g0u3BUzFDAtQ5.jFqLY13NhbMygy47hiHKWptG9SfUc2bDOdRu4YuschB5aJeSGPjIS f2_uLMQkkUawQ75J44xFODLSL1dbgU695dw0iJ3P9i4EV41Hvk7.iHw13mNJR69M9eUsQSUlDl9C RqTjrQopNBLn.LdOflIU1IsQy1YZ2Jyv9HCDg_zZPcu_q2gXReP6yq16alpyOj67JbbEpbtNB.Jq 4jW9JmUF7e5UDPkEANMqdldhsihR6BxBwDlxe5HM6O3SsyCrRgeQFlgdijoRwYIphCyKAXRCha1j wDum8ZllTes_qu2ubbFP.OGTtWrpricjWLUh1CKPCme0tno3dolX2WDb9WOQZSnWTppWoceqYsLF pDehPDb.Nh8fu.YeBQ2zLlV48IqFPpkF4x1q9AnybYxRHzQdIZsBbb665b8LY3g500kv6fHV0bNn 3wac3eUU04UY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Jul 2021 17:00:21 +0000 Received: by kubenode548.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 569d8eeb3c9ed09c9c658bfdbabbc931; Mon, 19 Jul 2021 17:00:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) In-Reply-To: Date: Mon, 19 Jul 2021 10:00:13 -0700 Cc: toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <603ADFF0-7F41-4CB0-B527-CA255586570A@yahoo.com> References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GT7Pz0rRGz4X4r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via toolchain X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jul-19, at 07:40, David Chisnall = wrote: > On 19/07/2021 13:35, Mark Millard via toolchain wrote: >> gcc is not documented to do automatically do such that I've >> found. >=20 > GCC is not Clang. GCC does not allow dynamically choosing the target. = If you want a GCC that targets aarch64-unknown-freebsd, then you must = build a copy of GCC that targets that triple. If you want a version of = clang that targets aarch64-unknown-freebsd, then you pass that to the = -target argument. [Mostly this fills in some detail rather than going in a different direction from your notes.] This I did not do. > The clang driver will provide a *default* value for the -target = argument if one is not provided. And it happens to be aarch64-unknown-freebsd14.0 in my context. >>> -flto requires LLD. You can force that with -fuse-ld=3Dlld. Clang = then will only find things called [{target triple}-]ld.lld >> If I specify -flto (which I did), why is the command invalid >> by definition (produces an error message) and so require more >> command line options to correct the behavior to not get an >> error? Why should the installation or removal of a incompatible >> tool chain change the status of the system's clang++ command >> line? >=20 > Clang does not know if ld is lld. It expects that the linker that you = provide is compatible with the linker arguments that you provide. If = lld is installed as {target}-ld, or if no {target}-ld exists and lld is = installed as {somewhere on the search path}/ld, then it will work. If = the linker installed on the search path is BFD or some other mostly = compatible ld, then it will work unless -flto is or some other linker = flag that is not compatible with that linker is specified. I am aware = of at least three other non-lld linkers that do support LTO with LLVM, Cool. [And a primary reason I wanted to reply.] > clang doesn't know, for all possible linkers you might have installed, = which ones support which flags. >=20 >> (The message is far from an obvious one as well, complaining >> about a missing file path.) >=20 > Note that this error comes from your linker, This was not obvious up front, but, yea, I figured it out before my initial question on the lists. > not clang. It is a bit odd that the base system clang tries to use = the gold plugin QUOTE from https://llvm.org/docs/GoldPlugin.html Building with link time optimization requires cooperation from the system linker. LTO support on Linux systems is available via the gold linker which supports LTO via plugins. This is the same mechanism used by the GCC LTO project. . . . The same plugin can also be used by other tools such as ar and nm. Note that ld.bfd from binutils version 2.21.51.0.2 and above also supports LTO via plugins. However, usage of the LLVM gold plugin with ld.bfd is not tested and therefore not officially supported or recommended. END QUOTE So if it is not using its own linker, clang presumes the plugin is appropriate, even when it was not built/installed? Possibly an "oddity" for a FreeBSD context but possibly a messy thing to track. (But the wording only allows for the "system linker" as well.) For reference: QUOTE You should produce bitcode files from clang with the option -flto. This flag will also cause clang to look for the gold plugin in the lib directory under its prefix and pass the -plugin option to ld. It will not look for an alternate linker without -fuse-ld=3Dgold, which is why you otherwise need gold to be the installed system linker in your path. ar and nm also accept the -plugin option and it=E2=80=99s possible to to install LLVMgold.so to /usr/lib/bfd-plugins for a seamless setup. If you built your own gold, be sure to install the ar and nm-new you built to /usr/bin. . . . --- command lines --- $ clang -flto a.c -c -o a.o # <-- a.o is LLVM bitcode file $ ar q a.a a.o # <-- a.a is an archive with LLVM = bitcode $ clang b.c -c -o b.o # <-- b.o is native object file $ clang -flto a.a b.o -o main # <-- link with LLVMgold plugin END QUOTE > but we don't install it. It should probably check for the existence = of LLVMgold.so and not pass it to the linker if it doesn't exist. Could well be. But does that get back into looking in a bunch of places to be sure, and to know what would be found based on which linker was used? May be too much of a mess to be practical. >> There is another message from me where I note that I'd figured >> out the -fuse-ld=3Dlld hack, although I omitted "ld." in the >> example: should have been aarch64-unknown-freebsd14.0-ld.lld . >> I'm actively using this technique because it seems to have the >> minimal other potential consequences. >=20 > If you do anything that depends on a specific linker or linker = behaviour (e.g. LTO) then specifying the linker to use is good practice, = not a 'hack'. As I understand, that other linker is supposed to be able to support LLVM's lto via the plugin. "This is the same mechanism used by the GCC LTO project." But: QUOTE You should produce bitcode files from clang with the option -flto. This flag will also cause clang to look for the gold plugin in the lib directory under its prefix and pass the -plugin option to ld. It will not look for an alternate linker without -fuse-ld=3Dgold, which is why you otherwise need gold to be the installed system linker in your path. END QUOTE But FreeBSD with -fuse-ld=3Dlld works instead of the non-existent linker that would go with -fuse-ld=3Dgold . This seems to be a FreeBSD mismatch with the documentation at https://llvm.org/docs/GoldPlugin.html . >> In the industry, it is fairly normal for a tool chain to >> have a place unique to it that wins unless something >> special is specified. (And that is after lots of >> variations have been tried over the decades.) I've tried >> to illustrate that with gcc but it is just one point and >> I do not claim there is universal following of such. >=20 > It is also normal in the industry for a toolchain to be non-modular = and to support a single target. Both of these were considered = anti-features by LLVM. Yep. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Jul 19 18:22:55 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3753E12A282F for ; Mon, 19 Jul 2021 18:22:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GT9FH16VVz4qpg; Mon, 19 Jul 2021 18:22:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 074432AEF; Mon, 19 Jul 2021 18:22:59 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.64] (host86-191-32-244.range86-191.btcentralplus.com [86.191.32.244]) by smtp.theravensnest.org (Postfix) with ESMTPSA id A6CF92AE2A; Mon, 19 Jul 2021 19:22:57 +0100 (BST) Content-Type: text/plain; charset=utf-8 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: Why is main's system clang (12.0.1-rc2) using /usr/local/bin/aarch64-unknown-freebsd14.0-ld ? (such breaks things) From: David Chisnall In-Reply-To: <603ADFF0-7F41-4CB0-B527-CA255586570A@yahoo.com> Date: Mon, 19 Jul 2021 19:22:55 +0100 Cc: toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <138904BA-12EA-439D-893C-BC8C4DFADB35@FreeBSD.org> References: <7073D16F-4505-4948-8232-A9618DF2FE5F.ref@yahoo.com> <7073D16F-4505-4948-8232-A9618DF2FE5F@yahoo.com> <77803112-7C05-40EA-9A46-8A5EB419950C@FreeBSD.org> <3B5C7A3A-344F-4CC7-A50D-56E391D04E59@yahoo.com> <0563fd33-75bd-ff16-2d37-ce62f15fa4a9@FreeBSD.org> <603ADFF0-7F41-4CB0-B527-CA255586570A@yahoo.com> To: marklmi@yahoo.com X-Mailer: Apple Mail (2.3445.104.21) X-ThisMailContainsUnwantedMimeParts: N On 19 Jul 2021, at 18:00, Mark Millard via toolchain = wrote: >=20 > [Mostly this fills in some detail rather than going in > a different direction from your notes.] Thanks. >> The clang driver will provide a *default* value for the -target = argument if one is not provided. >=20 > And it happens to be aarch64-unknown-freebsd14.0 in my context. I suspect that having the base system and ports use different vendor IDs = here would prevent any related problems. > QUOTE from https://llvm.org/docs/GoldPlugin.html > Building with link time optimization requires cooperation from the > system linker. LTO support on Linux systems is available via the > gold linker which supports LTO via plugins. This is the same > mechanism used by the GCC LTO project. >=20 > . . . The same plugin can also be used by other tools such as ar > and nm. Note that ld.bfd from binutils version 2.21.51.0.2 and > above also supports LTO via plugins. However, usage of the LLVM > gold plugin with ld.bfd is not tested and therefore not officially > supported or recommended. > END QUOTE >=20 > So if it is not using its own linker, clang presumes the plugin > is appropriate, even when it was not built/installed? Possibly > an "oddity" for a FreeBSD context but possibly a messy thing > to track. >=20 > (But the wording only allows for the "system linker" as well.) The wording here predates LLD and probably needs updating. It looks as = if the last time that file was touched was in 2018 and most of the text = is from 2013, before lld was useable: = https://github.com/llvm/llvm-project/commits/main/llvm/docs/GoldPlugin.rst= It=E2=80=99s still mostly true on non-FreeBSD platforms: On Linux, the = system linker is typically provided by GNU binutils and requires the = plugin. On macOS, the system linker is ld64 and does not require a = plugin. In both cases, the linker is maintained outside of the LLVM = project and is distributed separately. FreeBSD is quite unusual in taking the compiler and linker from the LLVM = project (though I believe there are plans for macOS to migrate from ld64 = to lld at some point). The other places that ship both tend to be = cross-compile toolchains (e.g. the Playstation SDK) and so do not use = the system linker. > For reference: >=20 > QUOTE > You should produce bitcode files from clang with the option > -flto. This flag will also cause clang to look for the gold > plugin in the lib directory under its prefix and pass the > -plugin option to ld. It will not look for an alternate > linker without -fuse-ld=3Dgold, which is why you otherwise > need gold to be the installed system linker in your path. >=20 > ar and nm also accept the -plugin option and it=E2=80=99s possible > to to install LLVMgold.so to /usr/lib/bfd-plugins for a > seamless setup. If you built your own gold, be sure to > install the ar and nm-new you built to /usr/bin. > . . . > --- command lines --- > $ clang -flto a.c -c -o a.o # <-- a.o is LLVM bitcode file > $ ar q a.a a.o # <-- a.a is an archive with LLVM = bitcode > $ clang b.c -c -o b.o # <-- b.o is native object file > $ clang -flto a.a b.o -o main # <-- link with LLVMgold plugin > END QUOTE >=20 >> but we don't install it. It should probably check for the existence = of LLVMgold.so and not pass it to the linker if it doesn't exist. >=20 > Could well be. But does that get back into looking in a > bunch of places to be sure, and to know what would be > found based on which linker was used? May be too much > of a mess to be practical. I was a bit surprised that it=E2=80=99s passed, because the default for = FreeBSD should be that the linker is lld-flavoured and so clang = shouldn=E2=80=99t need to pass it. It turns out that, for = compatibility, lld silently ignores being told to load the Gold plugin = and clang passes this argument even if it knows that the linker is LLD. >=20 >>> There is another message from me where I note that I'd figured >>> out the -fuse-ld=3Dlld hack, although I omitted "ld." in the >>> example: should have been aarch64-unknown-freebsd14.0-ld.lld . >>> I'm actively using this technique because it seems to have the >>> minimal other potential consequences. >>=20 >> If you do anything that depends on a specific linker or linker = behaviour (e.g. LTO) then specifying the linker to use is good practice, = not a 'hack'. >=20 > As I understand, that other linker is supposed to be able > to support LLVM's lto via the plugin. "This is the same > mechanism used by the GCC LTO project.=E2=80=9D Note that there is no guarantee that the linker in your path is lld or a = bfd ld, especially for Arm targets. The Arm linker, for example, does = not support LTO (I think - if it does, it doesn=E2=80=99t, neither do = some other proprietary linkers). > But: >=20 > QUOTE > You should produce bitcode files from clang with the > option -flto. This flag will also cause clang to look > for the gold plugin in the lib directory under its > prefix and pass the -plugin option to ld. It will not > look for an alternate linker without -fuse-ld=3Dgold, > which is why you otherwise need gold to be the > installed system linker in your path. > END QUOTE >=20 > But FreeBSD with -fuse-ld=3Dlld works instead of the > non-existent linker that would go with -fuse-ld=3Dgold . > This seems to be a FreeBSD mismatch with the > documentation at https://llvm.org/docs/GoldPlugin.html . -fuse-ld=3Dgold will cause LLVM to search for a linker whose name ends = ld.gold. The more I look at the docs, the more I realise that most of the docs = I=E2=80=99ve read about this are actually comments in the code. The = user facing docs are somewhat less than ideal. David From nobody Sun Jul 25 21:00:37 2021 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C248912D2FCA for ; Sun, 25 Jul 2021 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GXwSP4Pqvz3NSL for ; Sun, 25 Jul 2021 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4C0C82246 for ; Sun, 25 Jul 2021 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 16PL0b0g011521 for ; Sun, 25 Jul 2021 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16PL0bhO011520 for toolchain@FreeBSD.org; Sun, 25 Jul 2021 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202107252100.16PL0bhO011520@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: toolchain@FreeBSD.org Subject: Problem reports for toolchain@FreeBSD.org that need special attention Date: Sun, 25 Jul 2021 21:00:37 +0000 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16272468371.c1EcA6.10666" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16272468371.c1EcA6.10666 Date: Sun, 25 Jul 2021 21:00:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 234232 | clang Assertion failed when building the port dev Open | 245179 | lld: wrong/misleading "SHF_MERGE section size mus Open | 247665 | emulators/rpcs3: clang 10 crashes during build 3 problems total for which you should take action. --16272468371.c1EcA6.10666--