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)