From nobody Mon Aug 5 06:15:45 2024 X-Original-To: freebsd-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 4WcmQs0zpBz5Sdmg for ; Mon, 05 Aug 2024 06:16:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcmQq4MH6z4bn0 for ; Mon, 5 Aug 2024 06:16:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=He2s5+3a; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722838561; bh=vjGz+OGqZtyZf7xob4dFBl8jytjd+h04D9TP7Pk4Y6o=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=He2s5+3afUSlvIFgHlk/FPaN0Fo5Oa411vULikZ9dimIoVcHVbHwuO+Q88iFimTnNvsjbdB14qGEmP6oM4JvSXSHOHqrbb0w4wN9dCok5n9yOY3ASRTvPKimNQGDt9RNtQFbwtHhS4ubKRQsFPjCNOHZNlVpCH2YtTXP4dQui40zJPwJU4UhUrotlZVh6zCUdU4ZbvFUmT9t38OQxn10RfCEjjz5dyp0tBaTXpdb6ApuFTeRg0K9FPwZnt/8A4MKbtztcYtfUTIG1iWkkYsNdfXW1dWOXIYHWHFzadSSB1xBx2Dc6p7P6n/ipOwwMG3XRCfOH1Ber9yAffg1aCaDFQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722838561; bh=23ZJ42HMicW2UA4EVihPUeQ5/OlQ2bZfsSd/4jtQUq7=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZIMPrD3zUgx5FlkHH6BllKB7vjE8WkAeEfhEXJit+r8s935U0Sdj+it/O6pTnUqfBu23cCfAGsWUoHRFwEfVE3ZtkbDAxNEg7mroxvU9BzHOaomhoDloIdz9F/leaV1rQ5FrjBUnsw8JAJTZ0SyL6zQzGzagoaJCR3cItaXlmtEho14pBc9YuUM/l6AZba5Rqb3bMYBh2jiG/rDZ57H3gy3NQf/TNojdwnNj9qOfzVCFQMJCDSCcTQNMcKgQ9tj0OxTnkQ1yDETP4Ya47hLg/C8CeGb2WoTBEuN42Oenp8ckeiEWze0Knl5UnXDqGkNU5fyJGBZ38XeocWhq58N96w== X-YMail-OSG: SwVzw7gVM1mjvyuzen0yWx9l6DOZyXd.w1VHR4W8arfUK2GOXBe85c0MKACouPv RaL.rPYGetjlvvUGbCgV84Cn_bV.kapsOWJxGfzXZaBv5zayp6XyRYHnfSNe_pl2H.KEMzB.f4k_ 0m6pIUHDhX.lZqrJNXzFfC6qK1xLmigEF80B53bISPDXGFIAyvb3UlWIUvS4OksAgHkx78S3Qqu5 W.uihdNCI6CM22_mxnuJ2sMZJHLO0qOYvOVnysaT48m0icR8v3Q9UASD4tLvbxI1wAfB3926EYIN 9pAPRsJryRv6QjgYSCBLXSV2H8N1sor3Dqq5q3HWxC3C1ooNTwSmRGV4VZ0eiyUAWfrnFnVmAIWH 4P2DNONk.lTLgmqyvkViJpwhWuhsE7qox2eaB5GrvZUCOTUvqTWtW4ovALLRfb0V7opgQ0m5_qik DJGLG4SuupHCVUoKKGu29ax0yMpc7glwOCiyn.LqMKKCS_MyWAkiY7JbQ_3LhEuA8blu0uYdZoud n3KZxkBefudD2FNmmS1pTinBSr9DXezp4Sv2HWDrXxZV67WJTCKXicTzojC2_8sWoq2Jg0LnvPlu cnzSxBrpNqGAT9oQV0XF8GvsmjIpsqKNV5NS_kOg84R639sR8VGk2XogkldHexhCSK1pbUmfQ8Iw 0b5PGkXKXIpoNf1k9i3eAGT7JheKqWPv_c.2.cY3KObxWYegjV9OjZ0sBGsK8novijEb0F7KheID LO4xcdKvoMyBz3GpguZbGsXH7g8azTm7w.aC7ICFNAUQDKE0XgIRwwh_xkJJTNJpbsNzxuqseBx5 i7v2UV.V0TB7fqhw_JdKREHXa2iSbhDPqUFyDrOumnu5ZMa4bP07xedi0KaVCVx.6Cf.nif0_Agd .fNz8bH9Dl3xGRZ3yCey8bNqmNTaiVacMCSbXV5Jo9SJMgHMmzsagic2AQx7uSwuVFdLiyPigUXo TsdNvueUEiYDg0sm1QhrleD1ebyaPh8N8iH2IToL8jKJi1ePFyxUA0LbkffvwY47I8gcPYgFh8uK 8O2y49pEBjx.UyFRG4eolE6RyghykzYI7vfQ5iD5C6fED.vwhjJ9zL0E2zRbRQckTxRygdiP7Jls sZG6mW4whjo8JnCq.gy3sMPabMFrUdt2pQ_p2xwGV6.qyZ.TuEho_AB9KhuMTfLrTox8Z52HtX7V co4jwTca_4q20M01jEfBYYJ1L15N6_SmkliXKKdF9q3pv1o3Ak4mYdV7WOUpQChvpRJ1i8Y0JPu4 SwltZp9sQWa3nST5R1Xepo6epSEMzxVure5jyH1LOx.Y.N8NQTkMdDiQck5d97p4EHS6yq_y03.s TmHk2F_peiRDxUKbrlvrtfG_zn.n6AizOAbQbJ4U2GGh7pyHfTjpR4pIoARl.2TIDnduSg1cPBbY ltPVVif8HGHHrC9XEB4eij98_Dhvo7CXUDypt4uWAAtX8AtYy3a9XeyfXxpuvGORhSCCfQAhwsEB s0g8E2wzzEF_dyLhKubbTpZck4Id22RZgARcj4NvgKGqZKuk3yPy7j66c_lqq6Yd5B7yFwpIALOA FW5XIYHmHtEergPYKSNKKeeZIG.M6EiUZisNSrSZ3k89nsVVFh3SDo5cnISJeyUTzpA5YvAU7fCf PYhQ_8zYvtcyzK3F2hkvv6z.ZknZ9fMLYcGHHVBt.YVverGXn3j.eFgCmg_Ps8sfb1Fg2zAKSiQR o0oP6zHk5vWS6y57U28OL6LXsMU7PYFSwdBRXlgx4qiRXJmKS8PWbSM2DXnBMvwsZwWQMsj8CGqt rR2FkdmeGKtM1gybVoJBjO.0L58cqHN.j.SRA4_vN0w2wdinU8Ow0YUUGxZ7XaPLJXfeBbbIu56F Fe4fCcGiyAYkz8qfeaBtjp6WgJD6rFZqQEeNDrhXX2HmCGEVqNGM5D0Y0LRnNufQ3qrhSUlV.f0c fx4B.YWxhp7A858.rrCBI5K3CEUC98D26R5jGNyVdTisX8qok9gv9b9Kg4_aF.ynmpVTB9oMYBTc sTZs8aCMR9HGoMdS2RgX5CPWJ5HKqHOdVAFcE_mW8CJM9DMOpkK68RZCKavGC2mrcuau.S.IVKMD 3PJDWsSGarXaNtn0po4g53vU.MyUlNgfn7EBpgdRrzlhsMc0bqE._Kf0FdModjOJXsJySFaPiymw FjOT6RIeOzgplBKjEo6TGi1Xb5FXmPX2M4cGPBmJzRwYKu.a1zXRMZzAeZSNUuY.SfKBIDbuV9lE 8rFCm7TYTf8dnci7aupGd20Jdb8t83HukcLtq6Cv1F6DudJNl4UrMF0eTNGYtwW6QUGk6TxQArdt iYA-- X-Sonic-MF: X-Sonic-ID: 381ff592-bc21-495a-bb83-8e759561c448 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 06:16:01 +0000 Received: by hermes--production-gq1-5d95dc458-c8wt4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 31cd73eac0c109e33501e5d70b6e6d54; Mon, 05 Aug 2024 06:15:56 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? Date: Sun, 4 Aug 2024 23:15:45 -0700 References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> To: FreeBSD Toolchain , FreeBSD ARM List In-Reply-To: <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> Message-Id: <3D14B8AB-E8BF-497C-A84F-90F01A572FA5@yahoo.com> X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.91 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.907]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WcmQq4MH6z4bn0 On Aug 4, 2024, at 14:31, Mark Millard wrote: > On Aug 3, 2024, at 23:07, Mark Millard wrote: >=20 >> My recent attempts to build devel/llvm18 and devel/llvm19 in an armv7 = context (native or aarch64-as-armv7) have had /usr/bin/ld failures that = stop the build and report as: >>=20 >> LLVM ERROR: out of memory >> Allocation failed >>=20 >> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>=20 >> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>=20 >> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>=20 >> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>=20 >>=20 >> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >> at boot time: >>=20 >> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>=20 >> and later had "Max(imum)Obs(erved)" figures: >>=20 >> Mem: . . ., >> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>=20 >> Swap: 3685Mi Total, . . ., >> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>=20 >>=20 >> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>=20 >> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>=20 >> So lots of 4 GiByte or smaller processes would fit. >>=20 >=20 > Absent finding a way to get --threads=3D1 to be what is used, I > made the following crude way to test, built it, installed it > in the armv7 directory tree used for aarch64-as-armv7, and > then started an aarch64-as-armv7 test of building devel/llvm19 > to see what the consequences are (leading whitespace details > might not be preserved): >=20 > # git -C /usr/main-src/ diff contrib/llvm-project/ > diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp > index 8b2c32b15348..299daf7dd6fa 100644 > --- a/contrib/llvm-project/lld/ELF/Driver.cpp > +++ b/contrib/llvm-project/lld/ELF/Driver.cpp > @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList &args) = { > arg->getValue() + "'"); > parallel::strategy =3D hardware_concurrency(threads); > config->thinLTOJobs =3D v; > + } else if (sizeof(void*) <=3D 4) { > + log("set maximum concurrency to 1, specify --threads=3D to = change"); > + parallel::strategy =3D hardware_concurrency(1); > } else if (parallel::strategy.compute_thread_count() > 16) { > log("set maximum concurrency to 16, specify --threads=3D to = change"); > parallel::strategy =3D hardware_concurrency(16); >=20 > Basically, if the process address space has to be "small", avoid > any default memory use tradeoffs that multi-threading the linker > might involve --even if that means taking more time. >=20 > We will see if: >=20 > [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >=20 > still fails to build as armv7 vs. if the change leads it to > manage to build as armv7. The link attempt for "-o bin/llvm-exegesis" still failed: LLVM ERROR: out of memory Allocation failed A potentially interesting note is that: https://llvm.org/docs/CommandGuide/llvm-exegesis.html reports: QUOTE llvm-exegesis currently only supports X86 (64-bit only), ARM (AArch64 = only), MIPS, and PowerPC (PowerPC64LE only) on Linux for benchmarking. = Not all benchmarking functionality is guaranteed to work on every = platform. llvm-exegesis also has a separate analysis mode that is = supported on every platform that LLVM is. END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 5 07:15:40 2024 X-Original-To: freebsd-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 4Wcnlv1DXqz5Sk42 for ; Mon, 05 Aug 2024 07:15:55 +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.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wcnlt6ClYz4gSf for ; Mon, 5 Aug 2024 07:15:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722842153; bh=swk5YYSiygGmRUj0rCFqK2fzAQKERnT7C4F2RKWWfcA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Y54DBkF03sWxC4A+t5ldA6N7GImDsWepkqRZtIwCtA3opZ5Ca1hiBOoRbBI2GZQZFDEIUhr/O92f1W4TPIoh46CY/iXVAQDO38QrzE+5UZrXeOLSD/JITclBLseclcFlOMvYCzGjeC7w/VmcJdywxnDlSO5qChsaOyBQb0Zg28s8+vx8yzrO3OZ8+EhIRPSF17lIbCLN7NMtLzotwplq8o86zju8OyWI70RSxsQlgXZDimqcpsQFXi+E3kOnWxjTsd6GdaWRjmN0dtiKKewOXfJmc+pvZ59jrEHCoAZeECMc4OLvFA8yDt/QgrhAGMw+fgRxQm4uaW1vawSQMdMTGg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722842153; bh=PSOE2s9DRg5Kqjs7WN3A2Jchlu+XWLtG2SXkWly/hPU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=TeLo7frZf2xDo5MQN8l2QXwAB4XRXCI30sQ9C2JqraeutLxzQ3HFT1ZH3Qf9jGu1ich2o/skYTN3VEH18atXOgh18iji9eIAydmmF9uvckS3NzW2ZL21Pc4b5/VVQrRd5wwQjmUUtcwVkHsyrpBsxQSdUPiWeACdHvjQrmXWTLFBvQ0ovaobPS5zSN9ha7woB9eSAdKNLGw0B4h5X6wKm0pPhrFKyQTioIiQlzsDkwPpxQm68ze/hTl04hK0GExk/79xCVTUXb4QF2E87eUu9DrmOyX7jtm1Ouu96TAoc0qHUrKayDDnj6D//VKG95SkXlveq+DwJNjDxKylMI4Zeg== X-YMail-OSG: 8tNrN3gVM1mirgTkZxL6Ft9cpBcVEUFyNt5IIXn5GVi5sDdzYSqVD8XaujKzNjf qUK6eaqjHTUv..Tpyw_6qJqzsJuzhN8ySoT6nSVi_OzMPnxEQFckfn1JjRFmv_AI2wWLcIZQYp9l 5ukfbGUS6DRpDZ1FcBKct5fZXW0y8QcIFPPVOwqzZIYPZCzfStqXgB_tSiZUOld5ZQAqrRNOWf_K CAgbw8uTBeeKiXY6wwU26SQ0KG8ZbJhk..9WHcIWARTtEYtYE05EVRjZMeYJk0nmfi_HRtmRfNcK M1o6aArmvgBG5pt9gg2JUfjk3RKaGuBFI03pseuilR_BOp3dI8b_BE4TjsqI72gIpL2w97KRQOUz UGsghHtNANc40GPglWeiJCGiGnkKpe9aXsgVZSSQHFnWxZoGAsWzkKAV.GgHtVq9XLlxVnIuWmk0 MlZpAUjpTNKMYOAIWkx7tsrvPEmNAPjNydaZWadnY8aNbKtLn.l1M7ZE.j5FLy0Y..8RXtnWVt57 7IFl9ML0MPix4Y9JnRIOf.xSJyVUmiz1GJAGVxihJvg8iYnLHAoApItXi1ozahLgNgGKp4.IYTVZ z25Fk5fkIcB0lO8LbnVtfT5CM7xbOG7gsxP8r3a3F76HmIWb1KU7bteDBDQiWxX5u6xOxRO8Cgxz h.KV6IzjCwydBd3FIpIe4XD_LZiy52MIXeNJfQj34W18EuIyjoDniy9ah33CVT5ZONpJ8ikvSC6S YTBZPbh_WFS8pCd7KXCam.GCxVldQbj8WaZEwJmSqa0XfAxo9bYE94OfH3qkdcFN4ycPF1gmgfCW PrIEuPVu2d.rhPXZVIprVRFZ7Rd7Av1K0FBe7xS.VowjdAqbmfGObn_PkDtAJvf_IyMhsg0VczMv Zu7vPGyp.3uDz1jRuvhX9HQ6ZMwGndNxgGxTEupWCJaw52QrWpUmgVqycLo73Fu7UaX_2SVJ6H5F AEwx98YF927hl0yk5EXhCz12TCY3fOq3ykbtJqrhl5OXeGw3I9sEmD5Bi1zR8.wMs_pYm.Y.baRH OQblO.j15fAaKHyK0FsjEKExWtZaIpCQvnPpAXEf2G7z5XJ5b8Ygftuy1S_FtOC2VhyFCM2_TIBK YBFpfa9bxv5WCCI1y7aLVMQnelti3qcxHlVegtbv43T09WOHp6BvDgFOF4mbyVu9mXrw5DzVT4tO 87SQc5Ydsgj4My0landScxgY.BDaIH0uvxYZDhOPB21gilSGRc0BiC5jiQOxTX.ROG9x5nX.Hcvm 9XHlqR.ITMtmCkXgJgo04biyOGYmI95u3tMD8PLccT9.qLGkOTi809xRDgu8zMRUNc1HGU44jGpv TrqFb21rVYHeYyw7719Um4kapFcDUW5RfW5d5jgU5_8N3WVqQCzpoo1i9TG.o7JXrM8GK.kQ0aP8 ufBmpK8AjTZM4l7Llsvy9Uo7GW83H1obL2.IZn3D4u4YcToxpHSeaAmKc7zwpkb9KhiQSNWS0X3E dCLnVY8WsHKMf8gvwZrQYgwz3h4aIz_O7h08lasgebDHMFM3FBR3A11EMdceiAELx4np4Ezh..4. .0wjX00UhRNOVvxQEvNUOHexgl6kAhQuBTpBtxNiLcWGIPckyfsE188nnHNY6i1Q8BuY.hAmydUJ Vw1d4Hqwan28YlkSZahTNz1A6klWR7irXOekdtbenxdfHhBvJvlJ6sEwQgR6HniVrgLhDqZId3v0 gch5TpTTKhXZ8TEN.0K5Ul.F4QzBVhXLN2LAMAwg2eqkNtyO4FhOK4t5ANsYEk5GxYUmCEK.uR3I bttAnp6D1iDltPIU45jCrYLcCIUDpFVZhOsRsnCYV8lEB0cSW.RjmFlnD5SSkR8HTVIRJys5lkNL HOJcQnvhv_E330Act3w1nxZatoT3gHhxySkFUlyHzUDLPqsydrja1rL_abVaVS5zEjtQiXuFJ88m WgE.E5Wqvu35lXyKS70OZyI.vsS5eDUsggZj4XG4a_tuRkIzkqRk2cYiOe5DRLDYmRu52RPaxvs_ IF.nSVk84oJqJLbhsyGHyv6q9W5h3bFBI9gefKpFpOX4UcCm41TXmJSmrtqcuqjNVvHxNf_aBwMM 09EyCRgpewNR6VLmQ_pROjBDB_UT3mwYozaWdnV5tjFZCt.YnyyXCttasHUePcMXVstniSn8ije2 J2XCf5NMkjtIzeEZc4PSMW9KM38C4bWbbSSFcXvQoXindSyFUMTE6KIq_RRFFbYeXciSaJViu6oe SHy.4f8yV42A08Y6og0wRK6zhN0v49NqtJQekRMeiYB0hoITD4zC.ZBnWfIWQ7wuJFwNCO8i3vdc - X-Sonic-MF: X-Sonic-ID: e7391727-6347-4449-9d07-fa233211e59c Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 07:15:53 +0000 Received: by hermes--production-gq1-5d95dc458-24x88 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2ca5aa8b132b47836145f7a507b16d94; Mon, 05 Aug 2024 07:15:50 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: Date: Mon, 5 Aug 2024 00:15:40 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Wcnlt6ClYz4gSf On Aug 4, 2024, at 22:53, Michal Meloun wrote: > On 04.08.2024 23:31, Mark Millard wrote: >> On Aug 3, 2024, at 23:07, Mark Millard wrote: >>> My recent attempts to build devel/llvm18 and devel/llvm19 in an = armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures = that stop the build and report as: >>>=20 >>> LLVM ERROR: out of memory >>> Allocation failed >>>=20 >>> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>>=20 >>> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>>=20 >>> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>>=20 >>> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>>=20 >>>=20 >>> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >>> at boot time: >>>=20 >>> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>>=20 >>> and later had "Max(imum)Obs(erved)" figures: >>>=20 >>> Mem: . . ., >>> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>>=20 >>> Swap: 3685Mi Total, . . ., >>> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >>> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>>=20 >>>=20 >>> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>>=20 >>> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>>=20 >>> So lots of 4 GiByte or smaller processes would fit. >>>=20 >> Absent finding a way to get --threads=3D1 to be what is used, I >> made the following crude way to test, built it, installed it >> in the armv7 directory tree used for aarch64-as-armv7, and >> then started an aarch64-as-armv7 test of building devel/llvm19 >> to see what the consequences are (leading whitespace details >> might not be preserved): >> # git -C /usr/main-src/ diff contrib/llvm-project/ >> diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp >> index 8b2c32b15348..299daf7dd6fa 100644 >> --- a/contrib/llvm-project/lld/ELF/Driver.cpp >> +++ b/contrib/llvm-project/lld/ELF/Driver.cpp >> @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList = &args) { >> arg->getValue() + "'"); >> parallel::strategy =3D hardware_concurrency(threads); >> config->thinLTOJobs =3D v; >> + } else if (sizeof(void*) <=3D 4) { >> + log("set maximum concurrency to 1, specify --threads=3D to = change"); >> + parallel::strategy =3D hardware_concurrency(1); >> } else if (parallel::strategy.compute_thread_count() > 16) { >> log("set maximum concurrency to 16, specify --threads=3D to = change"); >> parallel::strategy =3D hardware_concurrency(16); >> Basically, if the process address space has to be "small", avoid >> any default memory use tradeoffs that multi-threading the linker >> might involve --even if that means taking more time. >> We will see if: >> [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >> still fails to build as armv7 vs. if the change leads it to >> manage to build as armv7. >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > I can build llvm18 and rust 1.79 on native armv7 without problems - = on Tegra TK1, without poudriere and on the ufs filesystem. IMHO = poudriere is unusable on 32bit systems. On Windows DevKit 2023 in a armv7 chroot I can build rust 1.79.0 as well. I've not tried a recent devel/llvm18 in that context, just devel/llvm19 . An armv7 process in this context can use about 1 GiByte more memory space than on the OrangePi+ 2ed. (See later program example outputs.) Previously, devel/llvm18-18.1.7 had built fine some time back. So I'm trying the modern 18.1.8_1 now on the Windows DevKit 2023. But this is with forcing of --threads=3D1 for lld: same context as the recent devel/llvm19 exploration. Note: UFS context, not ZFS. How does the Tegra TK1 context compare for the following program and the example command? OrangePi+ 2ed (so: armv7 native with 2 GiBytes of RAM): # more process_size.c // cc -std=3Dc11 process_size.c // ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 #include #include #include #include #include int main(int argc, char *argv[]) { size_t totalsize=3D 0u; for (int i =3D 1; i < argc; ++i) { errno =3D 0; size_t size =3D strtoul(argv[i],NULL,0); void *p =3D malloc(size); if (p) totalsize +=3D size; printf("malloc(%zu) =3D %p [errno =3D %d]\n", size, p, errno); } printf("approx. total, a lower bound: %zu MiBytes\n", = totalsize/1024u/1024u); return 0; } # cc -std=3Dc11 process_size.c # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 malloc(268435456) =3D 0x20800180 [errno =3D 0] malloc(268435456) =3D 0x30801980 [errno =3D 0] malloc(268435456) =3D 0x40802640 [errno =3D 0] malloc(268435456) =3D 0x50803600 [errno =3D 0] malloc(268435456) =3D 0x608048c0 [errno =3D 0] malloc(268435456) =3D 0x70805140 [errno =3D 0] malloc(268435456) =3D 0x80806580 [errno =3D 0] malloc(268435456) =3D 0x90807780 [errno =3D 0] malloc(268435456) =3D 0xa0808700 [errno =3D 0] malloc(268435456) =3D 0x0 [errno =3D 12] malloc(268435456) =3D 0x0 [errno =3D 12] malloc(268435456) =3D 0x0 [errno =3D 12] malloc(268435456) =3D 0x0 [errno =3D 12] malloc(134217728) =3D 0xb0809a00 [errno =3D 0] malloc(67108864) =3D 0x0 [errno =3D 12] malloc(33554432) =3D 0xb880a5c0 [errno =3D 0] malloc(16777216) =3D 0xba80b0c0 [errno =3D 0] malloc(8388608) =3D 0x0 [errno =3D 12] malloc(4194304) =3D 0x0 [errno =3D 12] malloc(2097152) =3D 0xbb80c180 [errno =3D 0] malloc(1048576) =3D 0xbba0de80 [errno =3D 0] approx. total, a lower bound: 2483 MiBytes Same program with same command on Windows DevKit 2023 in armv7 chroot (aarch64-as-armv7 with 32 GiBytes of RAM): # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 malloc(268435456) =3D 0x20800b00 [errno =3D 0] malloc(268435456) =3D 0x30801600 [errno =3D 0] malloc(268435456) =3D 0x40802cc0 [errno =3D 0] malloc(268435456) =3D 0x50803c80 [errno =3D 0] malloc(268435456) =3D 0x608042c0 [errno =3D 0] malloc(268435456) =3D 0x70805b00 [errno =3D 0] malloc(268435456) =3D 0x808063c0 [errno =3D 0] malloc(268435456) =3D 0x90807580 [errno =3D 0] malloc(268435456) =3D 0xa0808b40 [errno =3D 0] malloc(268435456) =3D 0xb0809980 [errno =3D 0] malloc(268435456) =3D 0xc080abc0 [errno =3D 0] malloc(268435456) =3D 0xd080ba00 [errno =3D 0] malloc(268435456) =3D 0xe080cc80 [errno =3D 0] malloc(134217728) =3D 0xf080d700 [errno =3D 0] malloc(67108864) =3D 0x0 [errno =3D 12] malloc(33554432) =3D 0xf880eb40 [errno =3D 0] malloc(16777216) =3D 0xfa80fc00 [errno =3D 0] malloc(8388608) =3D 0x0 [errno =3D 12] malloc(4194304) =3D 0xfb810840 [errno =3D 0] malloc(2097152) =3D 0xfbc117c0 [errno =3D 0] malloc(1048576) =3D 0xfbe12940 [errno =3D 0] approx. total, a lower bound: 3511 MiBytes Note: If the Tegra TK1 in question has more than 4 GiBytes of RAM, the command line should explore more than the example that I used. Note: I've used the program for other patterns of allocations. That is why it is not just a fixed exploration algorithm. As for poudriere-devel, I find it useful, even on the OrangePi+ 2ed. But mostly that is a rare run that is checking on how well the handling goes for the 2 GiByte of RAM context (with notable SWAP for the size of RAM). In other words, monitoring the growth in a context that will break sooner than my other contexts generally would. The tests take days overall, most of the time being for rust and a llvm* . Historically I've been able to have 2 builders, each with MAKE_JOBS_NUMBER_LIMIT=3D2 , so all 4 cores in use building lang/rust and a devel/llvm* at the same time successfully in poudriere-devel on the 2 GiByte OrangePi+ 2ed. (This was before recently imposing --threads=3D1 experiments, given the recent build failures.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 5 07:27:13 2024 X-Original-To: freebsd-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 4Wcp1G28tRz5SknC for ; Mon, 05 Aug 2024 07:27:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wcp1D2yLFz4hj9 for ; Mon, 5 Aug 2024 07:27:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PKS8wTxS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722842846; bh=i/yC5+matq9+pBRM+jnU8Kstb6NyrWubDQupnHd77jg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PKS8wTxSnfp4csmo1RgZKDOUgpzhtMyQLZgozy6AdyuWiwxXM2UNCYe/9fcclgbuZTtNj3W56elpFc9OO9qJo/oGhZbaagRjICMnVMjdRYJk9wC0GZ+XJBRQQfXPHcjQ3fGLKon3BXrjvcdML8+sy788VKY+qwk2VoYYEesxr1N0/rn49gVojF4AKnRw9uU+PTsy/zTk+tS+ZDvy4jOL9AzHtFXLeV88fObelvlXvmKW2THP66cfgeqzll5V71gmjSqmo4RHlqdAW8Oj0ZaSUugmU0+vqL7dpTNRqUBh9Zgro1pDE/r07UGPt35OR/oMhSe2ZCMeN6DSJACjWbcpig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722842846; bh=fJwLtwKOISGybkNAu3gdW071r7NifmHG1SFTSbZCBfJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gG1S+YxsTxBy61wM7z15LTI9waK++KHKIkp8ZTMhJ32LSTre3M8FRiVOl3tKglcK/a7CSEgd50QaZcCyr6QVMCP4DoAYRwwebwH4egzX9HtJQr4Ab0535s6/hkjl0FsBZKaYa3smXaXwC4Q0Wi71zZ3GgvaamRtrz7V1FRscezeCG9fGq5OPh2AaNsdXbvkeVlYphJheGJHtX4CWSiF+POPXCAsur01GYhdxP1JOLYQFmxBybIWUDByjalTfIrW2gV7Gpl4ZM7PAz5+HTbFR0l6izhA8/hgcu0SexdYc0123Zxil3+R8ScS31/LL9f4D+EMzWPq3X6QIutQugGDe+A== X-YMail-OSG: 2Oq1n.wVM1kFeg7LStpBzBYn3nCCSk0E_Oo5RmYHZH60dGHVI1Dgx9sqswkV7iy r.fCWXCjWc4Sk6RVErpOHNvqWWkNCf_MtHLf7Tdir2LZdd3AjYpeVRJfD8a6pdL9cPtVfkK0eKuv RYsB5E214Z4Eow9JzN8EWZO.eEieu14Jz5YZCwL3PicWv.sZtfodTiL.UM3qOhjEMijViYf72iMd G878w34mgkhKOJs66X.SfYDzh3IHT35y4xCqbi3N9nwzGxuHGfG5V3p5xJiEwk1Rkwr57Pq83u9Y rcRJhtT.INdl0GPvXmFQkcInAO1iUDp9ZsVv5t.EngxkjY3cvL.f.7aYSZPNDjt8axFmse0V08z6 9Pa0zfTVoNk0N_y8cFBCpQ3NtEfl_j7yX0TCjLfsVmlsMEOX1Fzjipx_X9yjcqIR_nIHjRz5U3Vq Dc1iFx6iGr49v5aq_2gVG3hxB5z49i61Rneaak_N.uYkOlfCS5vLHc_SKg6GTd0or.EaeWasz.rZ AW80hl6vFNVvDl18WCYvELWIvkUupcFaRxZkReLbybVlVJfLjqqwQHz6tei6h7xkr9tMLzlT9mWM V1iIdh1uryJ5WY_p4iyMob5RaKVxaEFH8a54B3gZ73eyD1VUB7Xw6uPulPXP196Yg.If_Moqw1CH 5cXMkx2m1XLuJocmJqdf8xTv1W.rbeYwx2C6dQm0wUk608Xtz43GVUrK2dGQLtRi7IcbXUSJ7wTo 1l_S.Qslc.zrpqb3u_TGxGDuPn_aUbpuuNP8wtlcgMPo1TpSbQBfueJtQR_mkaaSYKDigziloX_E 3pU5DPGwYkz.tXtugLPkYzOJ2BaO4GY4nZoWmqVxKpx0HxXQ4CQ.57W55.BYbMuy1dHpvQ9JhCMB x16EKJKl_fHDNvx0YcMnr61xinSZlMCh5fHpFlMYh7H7FU5.IdBxH4t92_.diO7JGE.Vu15j8zJx 6DeBP3sZj8QOiCO5CaIKkwQs1fTtT0Qg9y5dhypNBtuiZULEP5Mnem6vHwIFoOZVhopofUTEoGBe 3Oe9nDIZig6OwzHjjyc86uMceW5LlpRfMm_rPkA5OQwZ1ZwJ1U6iIwPPmN69TuefK9NwXtjcJwXM Igx6fyNJGFC8B9rw24KX4_1pc5EYv1a4R1fWtX.EzfsJD2WbZZgekSHQ06S98Xy6eNyxBuDLrPZQ 4rv24xaGqDqJF7o8iawqT4YJUk_I5qCLCvvCEZ7qA6D.B_ank5eKJet19A_Xsfv71vGYza_Shkzf YwKu_X1fLmet6ZL3_Jb_pfgnVgoFDoQAXVkIngOe3G3JWAL2l2pTnnf9E9TsemEzNda28NpVcLYv I65qH2bewlOjGshAEXSm_SlKjI0Js6RnVI_uVQ9mwV3o5ebWe06mZ4_xISuQBoUi_OpWOHqckyxS EeERGOMIxgPbYuPmLDsH_9Q1mlXk4krZ0Ptw_ibgEqafaJEehmbZCt_mgwZEbhVRrCKgt9nTOu5R XIeGrEcbNrDvY7Lga6zO4I35HC969frxuJz9H85xHPwDiMLsEuXx25SYyc8LJlFzIlsQRGdPPCqa g6zCRHZxVKSl8liLmREIoDG0w0IenI0To9WFztg_SYGVff9gz150UCYvKxjdqOpE30gv.Vp8Ewvj y1_c7_IVCB5cF2JqiOqTpNhPdUUDB7f.zP3i2ekk0uhEuD.1Tbn95uqvZR.dKUJYWeJZmsJrE76b .7jb6llKAdd_dsQSTVXv1M9dEOQ_dwCgzDbuTTqudWYIIYB8wx0pl0GoA80AviY.VbY3XfSzcJAs yQTlzBN3lINwB1SrJi2.ISdICronj4MweGN7jsPyYoc_QNkO2bK_rFz2lUVEpFyzy5LlmV7lEtKU QpIyJQ77zaJ93VWQ4K0excko8WLjgNidO8XpeliiIMaxBdntjCJx.DIQw.mDN9ezLXtXbx8DLqbd SlEPwPrz4gvl.ZIn.CDRu_ZUahyXb8uOKg11qSuWIzeg0Nq8aPyGwMx6.iH8U6iMBHRK9zNg_qQb U_NIrUTw_meEeb8BBsn2TOrXmSILhAZ3hRdF_oZ5S.j1yO6SrVEit0OrCStxICiKKA8Hx_ABBPIh O0rui01BnpNnGFtNHrj7HvaCUrhowyHJCyOySNrHFCkzAk2mb8Qy4Rbjw6fp4dg8YOsA8QFImi4C bsaLsqsBOQaNfiSdIMH8JeecgrafZCnfQsMk3XuFPi9vadGvH6EsyhAMLV9ivXjT6_t1edz_LW43 2RtmfhXEK9PRBU09OZreY7CMm4tj_il.DFbuRH8HkvGpOXCOmtzfeonuby6DHOxlGkEsXFeVupg- - X-Sonic-MF: X-Sonic-ID: 19a0e0d9-979a-49f4-b15e-c9369b5a855e Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 07:27:26 +0000 Received: by hermes--production-gq1-5d95dc458-5n5gs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f2d0b87131e3dc2b32fcce2abd96eba1; Mon, 05 Aug 2024 07:27:24 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: Date: Mon, 5 Aug 2024 00:27:13 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from] X-Rspamd-Queue-Id: 4Wcp1D2yLFz4hj9 On Aug 5, 2024, at 00:15, Mark Millard wrote: > On Aug 4, 2024, at 22:53, Michal Meloun = wrote: >=20 >> On 04.08.2024 23:31, Mark Millard wrote: >>> On Aug 3, 2024, at 23:07, Mark Millard wrote: >>>> My recent attempts to build devel/llvm18 and devel/llvm19 in an = armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures = that stop the build and report as: >>>>=20 >>>> LLVM ERROR: out of memory >>>> Allocation failed >>>>=20 >>>> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>>>=20 >>>> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>>>=20 >>>> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>>>=20 >>>> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>>>=20 >>>>=20 >>>> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >>>> at boot time: >>>>=20 >>>> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>>>=20 >>>> and later had "Max(imum)Obs(erved)" figures: >>>>=20 >>>> Mem: . . ., >>>> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>>>=20 >>>> Swap: 3685Mi Total, . . ., >>>> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >>>> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>>>=20 >>>>=20 >>>> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>>>=20 >>>> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>>>=20 >>>> So lots of 4 GiByte or smaller processes would fit. >>>>=20 >>> Absent finding a way to get --threads=3D1 to be what is used, I >>> made the following crude way to test, built it, installed it >>> in the armv7 directory tree used for aarch64-as-armv7, and >>> then started an aarch64-as-armv7 test of building devel/llvm19 >>> to see what the consequences are (leading whitespace details >>> might not be preserved): >>> # git -C /usr/main-src/ diff contrib/llvm-project/ >>> diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp >>> index 8b2c32b15348..299daf7dd6fa 100644 >>> --- a/contrib/llvm-project/lld/ELF/Driver.cpp >>> +++ b/contrib/llvm-project/lld/ELF/Driver.cpp >>> @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList = &args) { >>> arg->getValue() + "'"); >>> parallel::strategy =3D hardware_concurrency(threads); >>> config->thinLTOJobs =3D v; >>> + } else if (sizeof(void*) <=3D 4) { >>> + log("set maximum concurrency to 1, specify --threads=3D to = change"); >>> + parallel::strategy =3D hardware_concurrency(1); >>> } else if (parallel::strategy.compute_thread_count() > 16) { >>> log("set maximum concurrency to 16, specify --threads=3D to = change"); >>> parallel::strategy =3D hardware_concurrency(16); >>> Basically, if the process address space has to be "small", avoid >>> any default memory use tradeoffs that multi-threading the linker >>> might involve --even if that means taking more time. >>> We will see if: >>> [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >>> still fails to build as armv7 vs. if the change leads it to >>> manage to build as armv7. >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>=20 >> I can build llvm18 and rust 1.79 on native armv7 without problems - = on Tegra TK1, without poudriere and on the ufs filesystem. IMHO = poudriere is unusable on 32bit systems. >=20 > On Windows DevKit 2023 in a armv7 chroot I can build rust 1.79.0 > as well. I've not tried a recent devel/llvm18 in that context, > just devel/llvm19 . An armv7 process in this context can use > about 1 GiByte more memory space than on the OrangePi+ 2ed. (See > later program example outputs.) >=20 > Previously, devel/llvm18-18.1.7 had built fine some time back. > So I'm trying the modern 18.1.8_1 now on the Windows DevKit 2023. > But this is with forcing of --threads=3D1 for lld: same context as > the recent devel/llvm19 exploration. >=20 > Note: UFS context, not ZFS. >=20 > How does the Tegra TK1 context compare for the following > program and the example command? >=20 > OrangePi+ 2ed (so: armv7 native with 2 GiBytes of RAM): >=20 > # more process_size.c > // cc -std=3Dc11 process_size.c > // ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 >=20 > #include > #include > #include > #include > #include >=20 > int main(int argc, char *argv[]) > { > size_t totalsize=3D 0u; > for (int i =3D 1; i < argc; ++i) { > errno =3D 0; > size_t size =3D strtoul(argv[i],NULL,0); > void *p =3D malloc(size); > if (p) totalsize +=3D size; > printf("malloc(%zu) =3D %p [errno =3D %d]\n", size, p, errno); > } > printf("approx. total, a lower bound: %zu MiBytes\n", = totalsize/1024u/1024u); > return 0; > } > # cc -std=3Dc11 process_size.c > # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 > malloc(268435456) =3D 0x20800180 [errno =3D 0] > malloc(268435456) =3D 0x30801980 [errno =3D 0] > malloc(268435456) =3D 0x40802640 [errno =3D 0] > malloc(268435456) =3D 0x50803600 [errno =3D 0] > malloc(268435456) =3D 0x608048c0 [errno =3D 0] > malloc(268435456) =3D 0x70805140 [errno =3D 0] > malloc(268435456) =3D 0x80806580 [errno =3D 0] > malloc(268435456) =3D 0x90807780 [errno =3D 0] > malloc(268435456) =3D 0xa0808700 [errno =3D 0] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(134217728) =3D 0xb0809a00 [errno =3D 0] > malloc(67108864) =3D 0x0 [errno =3D 12] > malloc(33554432) =3D 0xb880a5c0 [errno =3D 0] > malloc(16777216) =3D 0xba80b0c0 [errno =3D 0] > malloc(8388608) =3D 0x0 [errno =3D 12] > malloc(4194304) =3D 0x0 [errno =3D 12] > malloc(2097152) =3D 0xbb80c180 [errno =3D 0] > malloc(1048576) =3D 0xbba0de80 [errno =3D 0] > approx. total, a lower bound: 2483 MiBytes >=20 >=20 > Same program with same command on Windows DevKit 2023 in > armv7 chroot (aarch64-as-armv7 with 32 GiBytes of RAM): >=20 > # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 > malloc(268435456) =3D 0x20800b00 [errno =3D 0] > malloc(268435456) =3D 0x30801600 [errno =3D 0] > malloc(268435456) =3D 0x40802cc0 [errno =3D 0] > malloc(268435456) =3D 0x50803c80 [errno =3D 0] > malloc(268435456) =3D 0x608042c0 [errno =3D 0] > malloc(268435456) =3D 0x70805b00 [errno =3D 0] > malloc(268435456) =3D 0x808063c0 [errno =3D 0] > malloc(268435456) =3D 0x90807580 [errno =3D 0] > malloc(268435456) =3D 0xa0808b40 [errno =3D 0] > malloc(268435456) =3D 0xb0809980 [errno =3D 0] > malloc(268435456) =3D 0xc080abc0 [errno =3D 0] > malloc(268435456) =3D 0xd080ba00 [errno =3D 0] > malloc(268435456) =3D 0xe080cc80 [errno =3D 0] > malloc(134217728) =3D 0xf080d700 [errno =3D 0] > malloc(67108864) =3D 0x0 [errno =3D 12] > malloc(33554432) =3D 0xf880eb40 [errno =3D 0] > malloc(16777216) =3D 0xfa80fc00 [errno =3D 0] > malloc(8388608) =3D 0x0 [errno =3D 12] > malloc(4194304) =3D 0xfb810840 [errno =3D 0] > malloc(2097152) =3D 0xfbc117c0 [errno =3D 0] > malloc(1048576) =3D 0xfbe12940 [errno =3D 0] > approx. total, a lower bound: 3511 MiBytes >=20 >=20 > Note: If the Tegra TK1 in question has more than > 4 GiBytes of RAM, the command line should explore > more than the example that I used. >=20 >=20 > Note: I've used the program for other patterns of > allocations. That is why it is not just a fixed > exploration algorithm. >=20 >=20 > As for poudriere-devel, I find it useful, even on > the OrangePi+ 2ed. But mostly that is a rare run > that is checking on how well the handling goes for > the 2 GiByte of RAM context (with notable SWAP for > the size of RAM). In other words, monitoring the > growth in a context that will break sooner than > my other contexts generally would. The tests take > days overall, most of the time being for rust and > a llvm* . >=20 > Historically I've been able to have 2 builders, > each with MAKE_JOBS_NUMBER_LIMIT=3D2 , so all 4 > cores in use building lang/rust and a devel/llvm* > at the same time successfully in poudriere-devel > on the 2 GiByte OrangePi+ 2ed. (This was before > recently imposing --threads=3D1 experiments, > given the recent build failures.) I should have noted that my normal devel/llvm* builds on aarch64 and armv7 avoid building: BE_AMDGPU and MLIR . They also target BE_NATIVE instead of BE_STANDARD . (aarch64 BE_NATIVE includes armv7 as well.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 5 07:42:01 2024 X-Original-To: freebsd-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 4WcpLM2x0Tz5SlpX for ; Mon, 05 Aug 2024 07:42:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcpLL1vLZz4kKh for ; Mon, 5 Aug 2024 07:42:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=e8g5gOaj; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722843736; bh=NYwAxZmSzL98MXgzGLJsVvOTHvAlhyA5vkl3OY+v7ug=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=e8g5gOajnCFgnzA9OHS6mv5c0HzWK6iVHlt7fQvUTva/RVrSiLfzixbTq+hjV5CvoYdGlLLxFbmOFiQrT9hlPpqcyCvWuY0ZevSnRHsAaz4buRwuQFPKEH+/fgqur7FQ2JMBCDWRJCXJiH85LlETxPi9Czk7o1/YsyjiGglfa7FBwrn+xOqTNYVyU/edhoePw+/x7G6BhYF4tE+RVDSTWmueI7hbGfgIZ1XnUwydjhPc9xQAfI2dhK3kO4bdhnJ9C4oD01Gw52/LOHiYobmti6AwEsNTxjLc1FTdHnzXD2xi34IJE6GjHNiqwh7I0QjrHOn9QNq0DO9VVEN0t0widA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722843736; bh=fayJwHjHP0ddT9Eg8/ABmG3rw97T4iZfx+Qijk+gtbp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=XssWPI5J2UTPO13MNxdPXobPScpeQFXiSq1fY5dyin1gMeAA8DlCtkkPkjFSC37WFQvvCcBTmtDYr4E7lsl9rXKqViYyQ3vDFJAIS8haoJ9czZmcMbepMloU52XCOgrKR3ZYIMdzmqfPq+cbQWCJ9WnvJd6fPzSwNY/uBYWCNCxMqN9g2Zd85KOQCVcKQgZST0pXpDlUZe+wm8luDd46dvMWAmOqlsfCm/EeVMzPJYjyupBhuDDpQDDZxZUw6k9vmeUWBhyRcnUww9Fy1d+zpO6y1g1TVfQAmtPEFWnkRrQngiWdujqmKK8wcQ8nVsCpqFQ++Q8hWhs17x7p914JSw== X-YMail-OSG: ieAL2c0VM1l_SLMsl1n._FqnsSlJFBBYi.F5wN_gzzBOjThDYCGe6xJKithRBCh 0U9ba6HTOPYo8pFaz7fK9brXKowBhq.OwYY2BsmP3UENGJn6h90hs8qhZh.Yebtd789YgDZMVlsd RzAZRzLnNNsF2rLQYXa0XIJlxhNldKhQZr.SUdZae.iDU.bYhrkiP6honDnVkqxkV07JuCIAB.b4 OfvV.7_o0.psUByTlkKmfl2G.p_.G5FwETIYtd.xz2j60mREF6UnEVhyjpjECKc4GcFokZ3YS_nd N8s8DitXBi13g4g8Uz4Ijn3aftnOCMh3KFc8_Uqm2Sho59RWipb8zBASdSmti_ejeJkFoNfJOF6p z0iFj8PoaT5wVT3MPtJYGEN.NJxoMxgwN2O3y9frGYCDJGsiPR.d6zwgO4XHrQIJjOxDpee2ZeHg NsaiXJyZ9a2xiXVDO9N0rx5rVzslzazsIwjHwLIsMlSFtXwG8ugl0cjlVY7ALiHi_BiVXFAc.HSu Wf0TWG8nTPXl03gG_I69TRI6L7LN6F8ibGH73kqnh7xIVimhoAXH6bjtP4uYxxcq.EXCijaL5wVH gyXSeIYjwMDqKj6sl0.NJlaE66yOr.6nONjzZKc3ZYF7GyH_wWiFK3CeNybbb1KE5F7AdjfifuBC pnZvSNgc5pU93GO8xpBCNpEInJN73poTJ7r7WjuklkV6b36o7WqHBuanbzsQKSVtI3CjmbyQ6xdS xBTXQxE0N38At5SxyXnl2qbH6R1oHn0HtnCPK3kYjx61z2Qw38EOosxHFQMY5mScrnU0B0cHH.qM t3XJPh4Z33qQFUN8BAmVc.wKwOvm2YUXF5ZBVYkYGxVy28mjvsTbVceH0XetxiRIf3T5u7QyetOy ienz7taRp0b.l0Y1MT7HonrQF.4ImPngWzapfce3EazMaDC6ioCYlNjDZYQy5F1IN.c8Kzylxnw1 .WZ0bPWj.0b3xe1ZQySGAz5Xoh9RvZCBOktqjLx5jNBG_Qm.08f8gbbqZGZiUOhnDwGghX_T7FYg sPmKSSqWU9PgOyS21eXO8LF.x_WiuzIqusXQJZhB3DsvgYo7kHrAJ31PgagqujbkaNjTD14VsYAP 9irLy56hix_Och.irFO25nzvpiO601jOc7PFxIBEoHiXswGLjqPgZxgZEwEuBUYINitfBUcDg8HV B.qNCQnIvudu8Sal8wp4zzh5rfCHEKlxjIzsolw03DNCF6KUcrreVY.DKl2FZO1Y_ctcZUJiUZrv e5CveF4VB3hSaJGpr1_5y5E_DpS8G79xhpTCIPzTvePGucq8AMukeFgKkIoCWXhu3u6WZ4vVTaGs WRuUmpCtDdRLmB4dbuYotE0mfanNEeAThl_J0Dr7tiOah9K5wx_OP07rcTGcLoc.OrIVGchLFuc6 x07TAkfiaKacB3XX3vXv6Ng2ASquxs7PUWrmmQLESf1.VuZUARePPO0.4J9_CdjwiUjF_Dg0jnNm UYyYrTiW9aQlxfSqJ9ikLnvLK5dd2luLOheNDh4JHWeVQADzBwbiSaYzsUCOG0vgUtjL3x74mzHZ lR02SRiN0KtZI.6Nzgiis.EeHwkc4MGEwze0PNtf4irT5sipBqsV4p8BQ8v0NsMwdvqJlpzUEPvv kZp3Rqddwo0BTfnRhaZmJ5yNsaNgibygNgDrI9_qYe9hUcegPZgvX4PyYP1qVP7IASRIO7BEatKa 7tY5whd110LRIfpCHR2SbXcRtSSaQ4XevwYpJbLP6coh1HubHkJhqf0bViTOn3.AFLcY12C.gZ_4 Di7h6uCoBRLlp3Yk4otHrd4dxl0G6qWHMy4mQjgJxvYpM.Hs2o04ogHUD36mB9tqhCorlK12z7po dkN2TmDKxczHRO66ecwk3pCYwgyrcnxJdDs9aFo9.u.dLZZW2l5NSjL1GT4e.Dq4eXLaVS9SaIwr Y8ISyXRiBkA6F_B8FP1.5bAqXXXUV38FYaQmjlTQLt1toCfQOk9bKJM7DdgpZQBXQabvo5ieAD.7 Ozke4GiQAED6zR8oFlXkFyUyWGscQsHi8VteC44zDJfYQbNz3MIfYU4XKAS7bxZvITaYg.MBw3wM dwiTjwezvVX0vlUOcexjyRgFG6_WOzR67WnTcqW8b29.tUp_3_Es3hWYq_nMVlSvk4Fq5YADgGHP zO5j.d0eKY8LjWCJsvgCxpJALjefxwCWZA.KK1JzMSuWjVFW4vIZeTR_82fwIwrcZOUKsW9l92Ai esla44Xgp9JbVyXQCr7JPUpdLXGKDL4YsfbykQvsaWb68mZWYla4qbWUW9s8_k7D6VyVVa08svyE - X-Sonic-MF: X-Sonic-ID: c89f68f0-970a-4bde-8634-849768c4d7f9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 07:42:16 +0000 Received: by hermes--production-gq1-5d95dc458-kk28l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3baa033702cd98f2c46b23c0c62fac3d; Mon, 05 Aug 2024 07:42:11 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: Date: Mon, 5 Aug 2024 00:42:01 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.82:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.82:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WcpLL1vLZz4kKh On Aug 5, 2024, at 00:27, Mark Millard wrote: > On Aug 5, 2024, at 00:15, Mark Millard wrote: >=20 >> On Aug 4, 2024, at 22:53, Michal Meloun = wrote: >>=20 >>> On 04.08.2024 23:31, Mark Millard wrote: >>>> On Aug 3, 2024, at 23:07, Mark Millard wrote: >>>>> My recent attempts to build devel/llvm18 and devel/llvm19 in an = armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures = that stop the build and report as: >>>>>=20 >>>>> LLVM ERROR: out of memory >>>>> Allocation failed >>>>>=20 >>>>> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>>>>=20 >>>>> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>>>>=20 >>>>> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>>>>=20 >>>>> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>>>>=20 >>>>>=20 >>>>> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >>>>> at boot time: >>>>>=20 >>>>> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>>>>=20 >>>>> and later had "Max(imum)Obs(erved)" figures: >>>>>=20 >>>>> Mem: . . ., >>>>> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>>>>=20 >>>>> Swap: 3685Mi Total, . . ., >>>>> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >>>>> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>>>>=20 >>>>>=20 >>>>> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>>>>=20 >>>>> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>>>>=20 >>>>> So lots of 4 GiByte or smaller processes would fit. >>>>>=20 >>>> Absent finding a way to get --threads=3D1 to be what is used, I >>>> made the following crude way to test, built it, installed it >>>> in the armv7 directory tree used for aarch64-as-armv7, and >>>> then started an aarch64-as-armv7 test of building devel/llvm19 >>>> to see what the consequences are (leading whitespace details >>>> might not be preserved): >>>> # git -C /usr/main-src/ diff contrib/llvm-project/ >>>> diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp >>>> index 8b2c32b15348..299daf7dd6fa 100644 >>>> --- a/contrib/llvm-project/lld/ELF/Driver.cpp >>>> +++ b/contrib/llvm-project/lld/ELF/Driver.cpp >>>> @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList = &args) { >>>> arg->getValue() + "'"); >>>> parallel::strategy =3D hardware_concurrency(threads); >>>> config->thinLTOJobs =3D v; >>>> + } else if (sizeof(void*) <=3D 4) { >>>> + log("set maximum concurrency to 1, specify --threads=3D to = change"); >>>> + parallel::strategy =3D hardware_concurrency(1); >>>> } else if (parallel::strategy.compute_thread_count() > 16) { >>>> log("set maximum concurrency to 16, specify --threads=3D to = change"); >>>> parallel::strategy =3D hardware_concurrency(16); >>>> Basically, if the process address space has to be "small", avoid >>>> any default memory use tradeoffs that multi-threading the linker >>>> might involve --even if that means taking more time. >>>> We will see if: >>>> [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >>>> still fails to build as armv7 vs. if the change leads it to >>>> manage to build as armv7. >>>> =3D=3D=3D >>>> Mark Millard >>>> marklmi at yahoo.com >>>=20 >>> I can build llvm18 and rust 1.79 on native armv7 without problems - = on Tegra TK1, without poudriere and on the ufs filesystem. IMHO = poudriere is unusable on 32bit systems. >>=20 >> On Windows DevKit 2023 in a armv7 chroot I can build rust 1.79.0 >> as well. I've not tried a recent devel/llvm18 in that context, >> just devel/llvm19 . An armv7 process in this context can use >> about 1 GiByte more memory space than on the OrangePi+ 2ed. (See >> later program example outputs.) >>=20 >> Previously, devel/llvm18-18.1.7 had built fine some time back. >> So I'm trying the modern 18.1.8_1 now on the Windows DevKit 2023. >> But this is with forcing of --threads=3D1 for lld: same context as >> the recent devel/llvm19 exploration. >>=20 >> Note: UFS context, not ZFS. >>=20 >> How does the Tegra TK1 context compare for the following >> program and the example command? >>=20 >> OrangePi+ 2ed (so: armv7 native with 2 GiBytes of RAM): >>=20 >> # more process_size.c >> // cc -std=3Dc11 process_size.c >> // ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>=20 >> #include >> #include >> #include >> #include >> #include >>=20 >> int main(int argc, char *argv[]) >> { >> size_t totalsize=3D 0u; >> for (int i =3D 1; i < argc; ++i) { >> errno =3D 0; >> size_t size =3D strtoul(argv[i],NULL,0); >> void *p =3D malloc(size); >> if (p) totalsize +=3D size; >> printf("malloc(%zu) =3D %p [errno =3D %d]\n", size, p, errno); >> } >> printf("approx. total, a lower bound: %zu MiBytes\n", = totalsize/1024u/1024u); >> return 0; >> } >> # cc -std=3Dc11 process_size.c >> # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 >> malloc(268435456) =3D 0x20800180 [errno =3D 0] >> malloc(268435456) =3D 0x30801980 [errno =3D 0] >> malloc(268435456) =3D 0x40802640 [errno =3D 0] >> malloc(268435456) =3D 0x50803600 [errno =3D 0] >> malloc(268435456) =3D 0x608048c0 [errno =3D 0] >> malloc(268435456) =3D 0x70805140 [errno =3D 0] >> malloc(268435456) =3D 0x80806580 [errno =3D 0] >> malloc(268435456) =3D 0x90807780 [errno =3D 0] >> malloc(268435456) =3D 0xa0808700 [errno =3D 0] >> malloc(268435456) =3D 0x0 [errno =3D 12] >> malloc(268435456) =3D 0x0 [errno =3D 12] >> malloc(268435456) =3D 0x0 [errno =3D 12] >> malloc(268435456) =3D 0x0 [errno =3D 12] >> malloc(134217728) =3D 0xb0809a00 [errno =3D 0] >> malloc(67108864) =3D 0x0 [errno =3D 12] >> malloc(33554432) =3D 0xb880a5c0 [errno =3D 0] >> malloc(16777216) =3D 0xba80b0c0 [errno =3D 0] >> malloc(8388608) =3D 0x0 [errno =3D 12] >> malloc(4194304) =3D 0x0 [errno =3D 12] >> malloc(2097152) =3D 0xbb80c180 [errno =3D 0] >> malloc(1048576) =3D 0xbba0de80 [errno =3D 0] >> approx. total, a lower bound: 2483 MiBytes >>=20 >>=20 >> Same program with same command on Windows DevKit 2023 in >> armv7 chroot (aarch64-as-armv7 with 32 GiBytes of RAM): >>=20 >> # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 >> malloc(268435456) =3D 0x20800b00 [errno =3D 0] >> malloc(268435456) =3D 0x30801600 [errno =3D 0] >> malloc(268435456) =3D 0x40802cc0 [errno =3D 0] >> malloc(268435456) =3D 0x50803c80 [errno =3D 0] >> malloc(268435456) =3D 0x608042c0 [errno =3D 0] >> malloc(268435456) =3D 0x70805b00 [errno =3D 0] >> malloc(268435456) =3D 0x808063c0 [errno =3D 0] >> malloc(268435456) =3D 0x90807580 [errno =3D 0] >> malloc(268435456) =3D 0xa0808b40 [errno =3D 0] >> malloc(268435456) =3D 0xb0809980 [errno =3D 0] >> malloc(268435456) =3D 0xc080abc0 [errno =3D 0] >> malloc(268435456) =3D 0xd080ba00 [errno =3D 0] >> malloc(268435456) =3D 0xe080cc80 [errno =3D 0] >> malloc(134217728) =3D 0xf080d700 [errno =3D 0] >> malloc(67108864) =3D 0x0 [errno =3D 12] >> malloc(33554432) =3D 0xf880eb40 [errno =3D 0] >> malloc(16777216) =3D 0xfa80fc00 [errno =3D 0] >> malloc(8388608) =3D 0x0 [errno =3D 12] >> malloc(4194304) =3D 0xfb810840 [errno =3D 0] >> malloc(2097152) =3D 0xfbc117c0 [errno =3D 0] >> malloc(1048576) =3D 0xfbe12940 [errno =3D 0] >> approx. total, a lower bound: 3511 MiBytes >>=20 >>=20 >> Note: If the Tegra TK1 in question has more than >> 4 GiBytes of RAM, the command line should explore >> more than the example that I used. >>=20 >>=20 >> Note: I've used the program for other patterns of >> allocations. That is why it is not just a fixed >> exploration algorithm. >>=20 >>=20 >> As for poudriere-devel, I find it useful, even on >> the OrangePi+ 2ed. But mostly that is a rare run >> that is checking on how well the handling goes for >> the 2 GiByte of RAM context (with notable SWAP for >> the size of RAM). In other words, monitoring the >> growth in a context that will break sooner than >> my other contexts generally would. The tests take >> days overall, most of the time being for rust and >> a llvm* . >>=20 >> Historically I've been able to have 2 builders, >> each with MAKE_JOBS_NUMBER_LIMIT=3D2 , so all 4 >> cores in use building lang/rust and a devel/llvm* >> at the same time successfully in poudriere-devel >> on the 2 GiByte OrangePi+ 2ed. (This was before >> recently imposing --threads=3D1 experiments, >> given the recent build failures.) >=20 > I should have noted that my normal devel/llvm* builds > on aarch64 and armv7 avoid building: BE_AMDGPU and > MLIR . They also target BE_NATIVE instead of > BE_STANDARD . (aarch64 BE_NATIVE includes armv7 as > well.) Looking around, I see that my Windows DevKit 2023 context still has /etc/sysctl.conf containing: # Help armv7 effectively have more address space: kern.maxssiz=3D67108864 kern.maxdsiz=3D536870912 That actually dates back to before some related commit(s) were done for the armv7 process size issue --and might not be useful any more. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 5 08:03:33 2024 X-Original-To: freebsd-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 4WcpqF1tnLz5Sn27 for ; Mon, 05 Aug 2024 08:03:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-21.consmr.mail.gq1.yahoo.com (sonic301-21.consmr.mail.gq1.yahoo.com [98.137.64.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcpqC4f8wz4p5f for ; Mon, 5 Aug 2024 08:03:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OYCgL0X6; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722845029; bh=nI3dKh3y+Tp5mtia27AKhXG9FO9yBVV/opjGisEy+LE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OYCgL0X6SHUHPBT7o8kqsOpc4hsoyXX1NzghVXA1ncEhJ+ifdI9pKeL/iwV5tCrNERW36rXE+a/mJWF5NsCwzVZHlYTYOIbgnVTAUPYDFlolhXlOw7hHYDr9xAyk4uOEYjU/du8LoSm1zOfM8GaS7tZLEJlZpkXkTVbiNeBv09EsBAnUQ38Pn701rDBZWQpMWHuXCRhiLn8zq233266OcEH5wFRhgFAYSwZ16qIOrzHhEaC52KC8utipbvFXBgPbsr2Lr0GxN/LeEVqC+vWAQDr6vUVJZA/+8XkgSJmVvhH0XDjCqylor+BTXMCqVJyOkBYGxmiGrA00iFgSuHYORw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722845029; bh=buknFxG+MUlElvCgpkYTSgSCNeH68nXiBSaYvh4mMdP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=BFTL/XKQzYyHrSVlwks0UADipQfCHDcfGx6etc8/kW6rSOyIX75bFOTAnOf0eaMGqIUGRZd9dNoiaVLJ/v7pWsXLoYyU5NZNyUtrfr7WO0yttt7/+15ht845CcZQuCAEwGj1U+DxOPF5w2upB8l/AZHJhvb46DgzrArdM+yn/zNUq8lThFYe56NZWDLOak+Fv0XgFZ4VT2eY906757X60XGuqbgYMC/T54kVn5EjC6jmXNY9yr0HPmRp0Hf2J2buAcSfltGe8IIx81Dly+OVW5HmdMS3di8QaXZLt5f/d+JrVVALAm9TV3L9v1q4DvweYRsKfYY4C1WgpO/E4eC8Og== X-YMail-OSG: VKYHSFYVM1laUVt2eJx_2.clTkKGNr4J7_59RJs6ynkQLZH8otGn2GcEM7Vsx9Y HqkUEwiz4XBAlr7v3Qtc9QtghX5m2uGdJW59ax0CHEz4oUUBJhX_hhONs6J8KKQ3rMU.Drl4hTRc SilY_2gB1JzX9xxlfkhuM3QfHa9twCjZcq23zVkGS75tahqgoz.QBlje4uevH756LZV.pNP6oRe_ E6nupc.naDAHg19qKFxsAdjDx72NMU.Y7749iqOX.eeCrIz9fnbYsg47iYdJij6DIwXyegvZanrf d7j1SObS15SF8EtJ0Qndrs5CXKmIQ1cgCXrjhfvpioFCwg1qs3AShESUSYrNbFyQwYYglt7y5gmL 5mESLu7iOMDnFGoYvTKCeKRFRelcORox4E6sPc1COH84TWkscN6fgQSQruHxdNsQ0VAotourV5E. 6ypuO25g3UFPYnVW1YKinbOTDrb7uACHiBFHSJIQ0Q6.64moz.6f4XaIDnvObkc1AtBnP30QMH_A lC4PX.FgMjMJiR.P8g7T.2tDD06_WitFMl5dyGu9aq05kQm8EMvs6jxApEQXoplp9p9wqv26b_Gw FG_63tFvWTYeOED3ipav21IpFFHBon.Km4aO6v_13Eu7GKySmALYDHebbW.KX8spvGeE5OPC9BnJ tzlz2bHvALYtNQT2B4N0rJGvvI1vp2pJAPHDv4zL3.gI5XSIxZSa0xDaY66F2ukDiVW2oW15veWc r54WxXtvjiUFxVkflHNfR4gP.DmFPHX2YYrYYzGcj8ZiK4ZepVm0mWysKFl5qpkvQUlpWTqvcw6z 5xyITtZA9q_Q943Guju4N.2ZcjuI.1JpaANopW2xw6GDD36AY.klFqtF7RVQdZsr6OSIitcmY5e4 DLalofxYHo.yU1QmLGIJ0nwucjWW9bw5U5nXcHYDxO3VBZygGz91FzBa4B_3g4SgUWS.KXYoqaiz FH2_UW4kFQA46qp0Fl7b8owSQxHnlmrMw0WvO1qjtFYGqnySknKzndZNZo8QqTLizASiy9Tb9J6Q qgBD1YPaYIk8Awri82Ga8RUw09r055WyGdrrEtGZWPgQ1gpPo_.V_MlQ9TFEb.dBwHSlNx6_8Ebc JYdZBiP6yuiArSb__mWz.s8PRPI6XWOCGCHPS.lfUSzO3wOTmyweJzndVOAoLpEqJsb7dtPQ0R2z OilNsDHtmXFm92nSYFoLXRX2v.druwEDyUnXKxPj7CTbepRreTj5fjXdEeFtAof6Nkw2WfwiO_.n 5Ds_flfaXBfpkJYzCBnNDEDCLQgx5.rBzXpozy7oZREpQUiEGQS1D7UIBrw6V3LrfMG0W3UP414. _BrEy0m6QDhUBdB7iIPaUPztLScnpavlWYVyAX9IvmH000ctPIu6LglQnwVNfvIr5KfNPTZtbVxg m6d032uQblOQcChT.V6l134CkfAzQpFbxYuytTbhcmo28ssp_9yabzZCxgx08GyUYathvcso206o sjJcRdCSRmG2dQ6fTQMsBXv_LJZSVGRAkhWeZ8LtEgSePLYUsxurjDlPwAKhG_I.w0lsXHJlnAb0 .3h2jA4FWlBzMomaTO0W3DyEpSYsFMtA7kt7inO5cOGUGD05CFHIedAfRTX2wq7JxZXnGG96WGxD 7UhN9HZ3q3_iJFHBMxDDYPOq0X9zjnHGkUzSUdQ5y3lWau04NrMhFLxyJBg1J3Ufr1SdSmUKUVOI a9nivbExc_wuLRJYfOSkk2oSCZU7.Tf8WFRYhm_NlO2OrAJUzVTRDS.9PEihbSPmnpPyQ3z3h5iJ QLIaJvvnUPsta.HvLc7XgR9LZTbiYHd45c6TVDt6reQH7X5mhcV1P0coTHp6QbKO_yz9KqRkxPGC dl5QjqwG5fqR35aNUhL0fnsYP7ZiZm1rLhN9G.zz.rBUIijeqJhaqS6YNDPLT2niG7za6V3TYUZy hXPFvb6rHv_RO2x4E3lXHUCvJ8Bh9H2KjeBfW9SngZ5jxy1saQii4opFAuGl4PJiC0VP2ovV4FEX 0eAShebiOxH7qLTlKIjRrm5JzhqyRtNJBIMkPswxdGsmw01pm_5r2FVtyvs5yq0l7i3rMs8.c4_i p9TCxFO.kMj2q_9Hq0Vu.ACI3EoWzabKDKbUyxURzS6IUHN4l4OX9sG6jVVFb.OwRE.dcex5_ZlT DDwWEu2LCvQrVuyfchpSjYSC2GQp5nj5HxjzF17758fAGTCZb9zxX9c9nCiLiKyvNAhqKxdHVCY1 1CU1fSlN7Qy_GwKR9OJ_OrLVDhYyohYdW5fvGQnY3JGbSWZ4fwk8g5ZngzQQYREgqFB0dgJEKzI. q X-Sonic-MF: X-Sonic-ID: 2b292a8d-9e90-45e8-b185-9e6150b0b412 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 08:03:49 +0000 Received: by hermes--production-gq1-5d95dc458-4hqnr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eba64bb6614871bfc178d450a22355ca; Mon, 05 Aug 2024 08:03:44 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: Date: Mon, 5 Aug 2024 01:03:33 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <6C2983D7-90E8-4CCF-B2A6-ACFE40BFB6A3@yahoo.com> References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.147:from] X-Rspamd-Queue-Id: 4WcpqC4f8wz4p5f On Aug 5, 2024, at 00:42, Mark Millard wrote: > On Aug 5, 2024, at 00:27, Mark Millard wrote: >=20 >> On Aug 5, 2024, at 00:15, Mark Millard wrote: >>=20 >>> On Aug 4, 2024, at 22:53, Michal Meloun = wrote: >>>=20 >>>> On 04.08.2024 23:31, Mark Millard wrote: >>>>> On Aug 3, 2024, at 23:07, Mark Millard wrote: >>>>>> My recent attempts to build devel/llvm18 and devel/llvm19 in an = armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures = that stop the build and report as: >>>>>>=20 >>>>>> LLVM ERROR: out of memory >>>>>> Allocation failed >>>>>>=20 >>>>>> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>>>>>=20 >>>>>> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>>>>>=20 >>>>>> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>>>>>=20 >>>>>> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>>>>>=20 >>>>>>=20 >>>>>> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >>>>>> at boot time: >>>>>>=20 >>>>>> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>>>>>=20 >>>>>> and later had "Max(imum)Obs(erved)" figures: >>>>>>=20 >>>>>> Mem: . . ., >>>>>> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>>>>>=20 >>>>>> Swap: 3685Mi Total, . . ., >>>>>> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >>>>>> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>>>>>=20 >>>>>>=20 >>>>>> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>>>>>=20 >>>>>> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>>>>>=20 >>>>>> So lots of 4 GiByte or smaller processes would fit. >>>>>>=20 >>>>> Absent finding a way to get --threads=3D1 to be what is used, I >>>>> made the following crude way to test, built it, installed it >>>>> in the armv7 directory tree used for aarch64-as-armv7, and >>>>> then started an aarch64-as-armv7 test of building devel/llvm19 >>>>> to see what the consequences are (leading whitespace details >>>>> might not be preserved): >>>>> # git -C /usr/main-src/ diff contrib/llvm-project/ >>>>> diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp >>>>> index 8b2c32b15348..299daf7dd6fa 100644 >>>>> --- a/contrib/llvm-project/lld/ELF/Driver.cpp >>>>> +++ b/contrib/llvm-project/lld/ELF/Driver.cpp >>>>> @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList = &args) { >>>>> arg->getValue() + "'"); >>>>> parallel::strategy =3D hardware_concurrency(threads); >>>>> config->thinLTOJobs =3D v; >>>>> + } else if (sizeof(void*) <=3D 4) { >>>>> + log("set maximum concurrency to 1, specify --threads=3D to = change"); >>>>> + parallel::strategy =3D hardware_concurrency(1); >>>>> } else if (parallel::strategy.compute_thread_count() > 16) { >>>>> log("set maximum concurrency to 16, specify --threads=3D to = change"); >>>>> parallel::strategy =3D hardware_concurrency(16); >>>>> Basically, if the process address space has to be "small", avoid >>>>> any default memory use tradeoffs that multi-threading the linker >>>>> might involve --even if that means taking more time. >>>>> We will see if: >>>>> [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >>>>> still fails to build as armv7 vs. if the change leads it to >>>>> manage to build as armv7. >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> marklmi at yahoo.com >>>>=20 >>>> I can build llvm18 and rust 1.79 on native armv7 without problems = - on Tegra TK1, without poudriere and on the ufs filesystem. IMHO = poudriere is unusable on 32bit systems. >>>=20 >>> On Windows DevKit 2023 in a armv7 chroot I can build rust 1.79.0 >>> as well. I've not tried a recent devel/llvm18 in that context, >>> just devel/llvm19 . An armv7 process in this context can use >>> about 1 GiByte more memory space than on the OrangePi+ 2ed. (See >>> later program example outputs.) >>>=20 >>> Previously, devel/llvm18-18.1.7 had built fine some time back. >>> So I'm trying the modern 18.1.8_1 now on the Windows DevKit 2023. >>> But this is with forcing of --threads=3D1 for lld: same context as >>> the recent devel/llvm19 exploration. devel/llvm18 18.1.8_1 on the Windows DevKit 2023 also got: FAILED: bin/llvm-exegesis . . . LLVM ERROR: out of memory Allocation failed I'll note that this is somewhat later than where the OrangePi+ 2ed allocation failures occurred for its 18.1.7 context. But the OPi+ 2ed context has a smaller effective process size limit as well. >>> Note: UFS context, not ZFS. >>>=20 >>> How does the Tegra TK1 context compare for the following >>> program and the example command? >>>=20 >>> OrangePi+ 2ed (so: armv7 native with 2 GiBytes of RAM): >>>=20 >>> # more process_size.c >>> // cc -std=3Dc11 process_size.c >>> // ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>>=20 >>> #include >>> #include >>> #include >>> #include >>> #include >>>=20 >>> int main(int argc, char *argv[]) >>> { >>> size_t totalsize=3D 0u; >>> for (int i =3D 1; i < argc; ++i) { >>> errno =3D 0; >>> size_t size =3D strtoul(argv[i],NULL,0); >>> void *p =3D malloc(size); >>> if (p) totalsize +=3D size; >>> printf("malloc(%zu) =3D %p [errno =3D %d]\n", size, p, errno); >>> } >>> printf("approx. total, a lower bound: %zu MiBytes\n", = totalsize/1024u/1024u); >>> return 0; >>> } >>> # cc -std=3Dc11 process_size.c >>> # ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>> malloc(268435456) =3D 0x20800180 [errno =3D 0] >>> malloc(268435456) =3D 0x30801980 [errno =3D 0] >>> malloc(268435456) =3D 0x40802640 [errno =3D 0] >>> malloc(268435456) =3D 0x50803600 [errno =3D 0] >>> malloc(268435456) =3D 0x608048c0 [errno =3D 0] >>> malloc(268435456) =3D 0x70805140 [errno =3D 0] >>> malloc(268435456) =3D 0x80806580 [errno =3D 0] >>> malloc(268435456) =3D 0x90807780 [errno =3D 0] >>> malloc(268435456) =3D 0xa0808700 [errno =3D 0] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(134217728) =3D 0xb0809a00 [errno =3D 0] >>> malloc(67108864) =3D 0x0 [errno =3D 12] >>> malloc(33554432) =3D 0xb880a5c0 [errno =3D 0] >>> malloc(16777216) =3D 0xba80b0c0 [errno =3D 0] >>> malloc(8388608) =3D 0x0 [errno =3D 12] >>> malloc(4194304) =3D 0x0 [errno =3D 12] >>> malloc(2097152) =3D 0xbb80c180 [errno =3D 0] >>> malloc(1048576) =3D 0xbba0de80 [errno =3D 0] >>> approx. total, a lower bound: 2483 MiBytes >>>=20 >>>=20 >>> Same program with same command on Windows DevKit 2023 in >>> armv7 chroot (aarch64-as-armv7 with 32 GiBytes of RAM): >>>=20 >>> # ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>> malloc(268435456) =3D 0x20800b00 [errno =3D 0] >>> malloc(268435456) =3D 0x30801600 [errno =3D 0] >>> malloc(268435456) =3D 0x40802cc0 [errno =3D 0] >>> malloc(268435456) =3D 0x50803c80 [errno =3D 0] >>> malloc(268435456) =3D 0x608042c0 [errno =3D 0] >>> malloc(268435456) =3D 0x70805b00 [errno =3D 0] >>> malloc(268435456) =3D 0x808063c0 [errno =3D 0] >>> malloc(268435456) =3D 0x90807580 [errno =3D 0] >>> malloc(268435456) =3D 0xa0808b40 [errno =3D 0] >>> malloc(268435456) =3D 0xb0809980 [errno =3D 0] >>> malloc(268435456) =3D 0xc080abc0 [errno =3D 0] >>> malloc(268435456) =3D 0xd080ba00 [errno =3D 0] >>> malloc(268435456) =3D 0xe080cc80 [errno =3D 0] >>> malloc(134217728) =3D 0xf080d700 [errno =3D 0] >>> malloc(67108864) =3D 0x0 [errno =3D 12] >>> malloc(33554432) =3D 0xf880eb40 [errno =3D 0] >>> malloc(16777216) =3D 0xfa80fc00 [errno =3D 0] >>> malloc(8388608) =3D 0x0 [errno =3D 12] >>> malloc(4194304) =3D 0xfb810840 [errno =3D 0] >>> malloc(2097152) =3D 0xfbc117c0 [errno =3D 0] >>> malloc(1048576) =3D 0xfbe12940 [errno =3D 0] >>> approx. total, a lower bound: 3511 MiBytes >>>=20 >>>=20 >>> Note: If the Tegra TK1 in question has more than >>> 4 GiBytes of RAM, the command line should explore >>> more than the example that I used. >>>=20 >>>=20 >>> Note: I've used the program for other patterns of >>> allocations. That is why it is not just a fixed >>> exploration algorithm. >>>=20 >>>=20 >>> As for poudriere-devel, I find it useful, even on >>> the OrangePi+ 2ed. But mostly that is a rare run >>> that is checking on how well the handling goes for >>> the 2 GiByte of RAM context (with notable SWAP for >>> the size of RAM). In other words, monitoring the >>> growth in a context that will break sooner than >>> my other contexts generally would. The tests take >>> days overall, most of the time being for rust and >>> a llvm* . >>>=20 >>> Historically I've been able to have 2 builders, >>> each with MAKE_JOBS_NUMBER_LIMIT=3D2 , so all 4 >>> cores in use building lang/rust and a devel/llvm* >>> at the same time successfully in poudriere-devel >>> on the 2 GiByte OrangePi+ 2ed. (This was before >>> recently imposing --threads=3D1 experiments, >>> given the recent build failures.) >>=20 >> I should have noted that my normal devel/llvm* builds >> on aarch64 and armv7 avoid building: BE_AMDGPU and >> MLIR . They also target BE_NATIVE instead of >> BE_STANDARD . (aarch64 BE_NATIVE includes armv7 as >> well.) >=20 >=20 > Looking around, I see that my Windows DevKit 2023 context > still has /etc/sysctl.conf containing: >=20 > # Help armv7 effectively have more address space: > kern.maxssiz=3D67108864 > kern.maxdsiz=3D536870912 >=20 > That actually dates back to before some related commit(s) > were done for the armv7 process size issue --and might > not be useful any more. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 5 09:09:24 2024 X-Original-To: freebsd-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 4WcrH7381gz5St0Q for ; Mon, 05 Aug 2024 09:09:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WcrH65T7Xz4tm0 for ; Mon, 5 Aug 2024 09:09:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722848977; bh=rIp7e1CQsdmXZkXTWmZe7lXHcO6OV/sk+23xKOO6Owg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hASqOE1gP5uqWOpM2e/nTzS4U+rPdbVtvFSICRlZR186xlfkuM7r2Mf3z+zM3sJ+gXujjSw7Q1tSe0FNGyqWHz0LxwjPkvSZV2QNIjD1vjKaPTEjQmUC5WUr20ISVJwq+MABgHJsQ1jbkO6UE1RKFfYrpZKbkWU2GIgt9gUOQ7AvFiVlSLRRn/Gccg9ylwmFTo51My5SKxOdQFhxMF6mkqc8wgA72TnIQJh4zrK+otgQFOYdijG/1L+ulFuCLy33Tc0VC5el+feR1uwk3Kt/Vt0bPTyc9N8pTfuy0+WDdsNAXc/jeSjqpX/CsgsQjj5sY6es6mpsJs++JXeJRSjIQA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722848977; bh=HGjs0DnDMc7QmMrFNHdV/G7HURHXBQG3NjbHj7AA1Xn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=nAYCMZOElMRW+Uz8iPqR4iYREPtZxcBPX3TkPKf5qM5lHHnPXhEdpYvhCURPscnf7B45Ae3fy+gvuspse7gMQibJQE/MhM0Nhkm5KT+UTYv3fpk14VbaPQM2DrEmjdCmKEhq8vlFbf/BoJjSsgvW5tPqo2ly6dWLEuKvRLc2eS4il/pvsD1qNAeDJ9p0zysC/QB09Cq4lUNCMecJp8KRHP2BD8QYEsf2DCy3vgrME+EL2dq1m3DkDpD8pxrQo5iMOlBNanFV75sIv2Ls7ElAq6BP4BTuNo+uuLg1VvoD4EjlutU6fBOe1HcTvjl45LzktOhLDqhFZ9Lc0uD1KbvoGA== X-YMail-OSG: Dl074xcVM1lWkz6AxrPmfWvatAD1YgOjB27iWT1ELEKADeD_QdIN15sBZlu3jmx T3p15oUUaN1GZzEZeAfmu9ETf2ccVBubLDUYZl7g9soVP_o5lRDVsxQb2PAPYFdLyZQGuwPyfUvX IXGfe9HjLQdik2XRZYrkormx7B1O9rp.fqU9Sqm8Sx8fPIbeYrSc8nGwcfdtwQoWnrH1YiUltkF6 bT_AWBuvgs1kXpcYTgc0SFQOCKh7WXan4wAPiT9WVmcCb.yoz9vRKsz_ktHhTd67rIPk2roYQXyd xi8ij1sNSf52kYxqgBejHb9dJbedGZwTyMS1mjxUZqr2qixeMn5ACVsMDm_fFquJXjRXdlCK9Wa4 NjFwHgxAI855mnrXaDJnTi38iwzt270DsQWq..muK_yGjFGXtumsRAVdbdVYb7ttQNh9qnHZFLSV om47_ubgH4_VmFeY65ijQjOKLioVYL2U5gRP66PGPt9P2C22OZ2cx1ZCG9JVWVLT7X9akFJsazoP Jw4J7GiIclwzjraGOkSnoG7iyjqFgz4.HKCWbh7ih_Z9RWbZK5qYUv.T36ETQ9mm4BNfQHrzbJZV IP4CK5Wvcm9TfZYe.Vu6AqNP3WRHtqja6kwXJI96hZBpOuTrCHnvP2XsAfJ9grlPvTN_Gxdon58W QJ5G9mUI7EYMNZVnQpVky34pvUmhLM0C5fwIzomei0pwzYxaqVIXJqE3yOQ2o2YgP5t0xnobkqS0 IFH5JPk.cRjP6KgqUkgSyvTSA6S26JbnTLtKMVhtl2hUnFO6DBf3IS0TIcT9RQTF6X9MFNfMV_pu lHXbCm7ZCQg3_Fkp.82W7SGp5fjNsH1DRkPGYvGvLEb6aYazgSsk5Y_Mu5AnZpGbmNMVio4gtOIO w2MiMiogejtghfwWnESPYl0baM7DXmnvpsZY8Es3g_vqQ6fpqUoB8tPJ54cOPiRiAUJC0DGglCIg K1.0X76yDuE2wc7YpCrKAjJopbHz4o2Ro2jUHaeVlmY14uJVgZyJMW57wrDCQko88oBxEEIhsHxY sXwWc7MQQ2DPisIDuY.igciKfEyOJ5NyibhP__YUGDYqOlZlDsMGURPt3PDq7JR3pGRRSab0JkF6 LCxx8Ra.5ZnghR.8r4W5tT1GHmyq5dNlVIHhW3TocuA7EC9JTRRjmKB.GkTDhUeradOFJkjeMlgS pRiLtPu30.KblGdoEfX5FF0DHo3Evbkd256PyP3U5Lygv9Uq70w4lw4F5sS_FVBoxriodrZKcKU3 .dHFEWZ7C6BKcrMU0LHGl1xsxIxonS1_2fsR1neNRW4sBW5RNDnzCzOj05oo80BiaWaZXGIsrZg4 ExnuSdThCk3o_RS92BEF_XCkOF_y4F63tW_PZo6EY_RpYQShIIlDxMG.xojsEnQ1tQSJ7gbXG1yr GHLpxqK3xjBZuxmMOJHOT9QMp.K2iguDOIvJnhYpjE7OEu8aLrfQcaJfEZHL4_19C.HE8eJellj3 8VA27iglamEIayYLuK95R6HvuIPFhQPWLrLyq6RMxaFHPOahs..7wbQ.UKWaPWKk0QukdPbTqKjD d26Nl6P5mskWHk4juypDJ4p2W98s4YoUBvObYfPejzSPpCUqcR8JQjEDqBKClwNHnNK5j7xBjNCG a_QEIaBGmynT5D7VGJ1TglvpkbHJS14G1R1X6kK9CGC4PjVrcMe9VxsusuVmcgXAiYmoRkLwYyzO mu.N82F0wV5K.Q.0XMsYo9hnmEV4Zarx1O_yXoMYffYLU3GNFnLqx.6zWbhgX2FHoPOCgOHqqj9e yL78qci75UOhoYsRvToklaiOG06x8fq.Uce98oq0wxQ4rrFGs8zfeDOflVqtABAU45dd7MlvCY5C iFs2lFQe4UmYA1nVgssAGwcM_fLM5x_hHzPT0SIORLF5wCr_6UtHr29XtR9NdzGD03xA5mY2c4r. iInIKoKjXF4bAnVGoqITwmAHW9wCiqIu995mluXORfvm6q39pzdGZW1P9XDiUea4Ld3Vi5tLfFbw qGDwGMOF2._ZaOqRdV2PJVv76OYVsnkPgQag38ITZXRHYAOyYsPhPL6XNQf0J6m8d1rb_.FSeogv STPHW6R10xEw.A8gFviRLqBDqEZX4vuTZ7mJIj9esKzrU_gqrCg0YI_bacrFQVwQ24qTSrsG.Bjk eDOLiOuozxEX_hT.lgV21VUChyGOOXfYxLeTaWVM4E7iM5auzHWWxxLZPhs46SQyHcJzcnK3Z0cx O7_KCQ2NcxaWFDljYiD7Y1cPxD2x8qbUH2Bk2WrQVsErGZExH_oUVn04WYN9aqNHjdgK1YQPpDL6 Z X-Sonic-MF: X-Sonic-ID: 89c6b3e5-6d9b-4c02-9234-81f5a0716584 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 09:09:37 +0000 Received: by hermes--production-gq1-5d95dc458-rvnnh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bba17240621277e84a4239334ea13fe0; Mon, 05 Aug 2024 09:09:34 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: <0b3b532c-ae94-439c-81aa-9e80a08af43f@freebsd.org> Date: Mon, 5 Aug 2024 02:09:24 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> <0b3b532c-ae94-439c-81aa-9e80a08af43f@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WcrH65T7Xz4tm0 On Aug 5, 2024, at 00:44, meloun.michal@gmail.com wrote: > On 05.08.2024 9:27, Mark Millard wrote: >> On Aug 5, 2024, at 00:15, Mark Millard wrote: >>> On Aug 4, 2024, at 22:53, Michal Meloun = wrote: >>>=20 >>>> On 04.08.2024 23:31, Mark Millard wrote: >>>>> On Aug 3, 2024, at 23:07, Mark Millard wrote: >>>>>> My recent attempts to build devel/llvm18 and devel/llvm19 in an = armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures = that stop the build and report as: >>>>>>=20 >>>>>> LLVM ERROR: out of memory >>>>>> Allocation failed >>>>>>=20 >>>>>> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>>>>>=20 >>>>>> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>>>>>=20 >>>>>> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>>>>>=20 >>>>>> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>>>>>=20 >>>>>>=20 >>>>>> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >>>>>> at boot time: >>>>>>=20 >>>>>> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>>>>>=20 >>>>>> and later had "Max(imum)Obs(erved)" figures: >>>>>>=20 >>>>>> Mem: . . ., >>>>>> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>>>>>=20 >>>>>> Swap: 3685Mi Total, . . ., >>>>>> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >>>>>> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>>>>>=20 >>>>>>=20 >>>>>> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>>>>>=20 >>>>>> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>>>>>=20 >>>>>> So lots of 4 GiByte or smaller processes would fit. >>>>>>=20 >>>>> Absent finding a way to get --threads=3D1 to be what is used, I >>>>> made the following crude way to test, built it, installed it >>>>> in the armv7 directory tree used for aarch64-as-armv7, and >>>>> then started an aarch64-as-armv7 test of building devel/llvm19 >>>>> to see what the consequences are (leading whitespace details >>>>> might not be preserved): >>>>> # git -C /usr/main-src/ diff contrib/llvm-project/ >>>>> diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp >>>>> index 8b2c32b15348..299daf7dd6fa 100644 >>>>> --- a/contrib/llvm-project/lld/ELF/Driver.cpp >>>>> +++ b/contrib/llvm-project/lld/ELF/Driver.cpp >>>>> @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList = &args) { >>>>> arg->getValue() + "'"); >>>>> parallel::strategy =3D hardware_concurrency(threads); >>>>> config->thinLTOJobs =3D v; >>>>> + } else if (sizeof(void*) <=3D 4) { >>>>> + log("set maximum concurrency to 1, specify --threads=3D to = change"); >>>>> + parallel::strategy =3D hardware_concurrency(1); >>>>> } else if (parallel::strategy.compute_thread_count() > 16) { >>>>> log("set maximum concurrency to 16, specify --threads=3D to = change"); >>>>> parallel::strategy =3D hardware_concurrency(16); >>>>> Basically, if the process address space has to be "small", avoid >>>>> any default memory use tradeoffs that multi-threading the linker >>>>> might involve --even if that means taking more time. >>>>> We will see if: >>>>> [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >>>>> still fails to build as armv7 vs. if the change leads it to >>>>> manage to build as armv7. >>>>> =3D=3D=3D >>>>> Mark Millard >>>>> marklmi at yahoo.com >>>>=20 >>>> I can build llvm18 and rust 1.79 on native armv7 without problems = - on Tegra TK1, without poudriere and on the ufs filesystem. IMHO = poudriere is unusable on 32bit systems. >>>=20 >>> On Windows DevKit 2023 in a armv7 chroot I can build rust 1.79.0 >>> as well. I've not tried a recent devel/llvm18 in that context, >>> just devel/llvm19 . An armv7 process in this context can use >>> about 1 GiByte more memory space than on the OrangePi+ 2ed. (See >>> later program example outputs.) >>>=20 >>> Previously, devel/llvm18-18.1.7 had built fine some time back. >>> So I'm trying the modern 18.1.8_1 now on the Windows DevKit 2023. >>> But this is with forcing of --threads=3D1 for lld: same context as >>> the recent devel/llvm19 exploration. >>>=20 >>> Note: UFS context, not ZFS. >>>=20 >>> How does the Tegra TK1 context compare for the following >>> program and the example command? >>>=20 >>> OrangePi+ 2ed (so: armv7 native with 2 GiBytes of RAM): >>>=20 >>> # more process_size.c >>> // cc -std=3Dc11 process_size.c >>> // ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>>=20 >>> #include >>> #include >>> #include >>> #include >>> #include >>>=20 >>> int main(int argc, char *argv[]) >>> { >>> size_t totalsize=3D 0u; >>> for (int i =3D 1; i < argc; ++i) { >>> errno =3D 0; >>> size_t size =3D strtoul(argv[i],NULL,0); >>> void *p =3D malloc(size); >>> if (p) totalsize +=3D size; >>> printf("malloc(%zu) =3D %p [errno =3D %d]\n", size, p, errno); >>> } >>> printf("approx. total, a lower bound: %zu MiBytes\n", = totalsize/1024u/1024u); >>> return 0; >>> } >>> # cc -std=3Dc11 process_size.c >>> # ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>> malloc(268435456) =3D 0x20800180 [errno =3D 0] >>> malloc(268435456) =3D 0x30801980 [errno =3D 0] >>> malloc(268435456) =3D 0x40802640 [errno =3D 0] >>> malloc(268435456) =3D 0x50803600 [errno =3D 0] >>> malloc(268435456) =3D 0x608048c0 [errno =3D 0] >>> malloc(268435456) =3D 0x70805140 [errno =3D 0] >>> malloc(268435456) =3D 0x80806580 [errno =3D 0] >>> malloc(268435456) =3D 0x90807780 [errno =3D 0] >>> malloc(268435456) =3D 0xa0808700 [errno =3D 0] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(268435456) =3D 0x0 [errno =3D 12] >>> malloc(134217728) =3D 0xb0809a00 [errno =3D 0] >>> malloc(67108864) =3D 0x0 [errno =3D 12] >>> malloc(33554432) =3D 0xb880a5c0 [errno =3D 0] >>> malloc(16777216) =3D 0xba80b0c0 [errno =3D 0] >>> malloc(8388608) =3D 0x0 [errno =3D 12] >>> malloc(4194304) =3D 0x0 [errno =3D 12] >>> malloc(2097152) =3D 0xbb80c180 [errno =3D 0] >>> malloc(1048576) =3D 0xbba0de80 [errno =3D 0] >>> approx. total, a lower bound: 2483 MiBytes >>>=20 >>>=20 >>> Same program with same command on Windows DevKit 2023 in >>> armv7 chroot (aarch64-as-armv7 with 32 GiBytes of RAM): >>>=20 >>> # ./a.out 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 134217728 67108864 33554432 16777216 8388608 4194304 2097152 = 1048576 >>> malloc(268435456) =3D 0x20800b00 [errno =3D 0] >>> malloc(268435456) =3D 0x30801600 [errno =3D 0] >>> malloc(268435456) =3D 0x40802cc0 [errno =3D 0] >>> malloc(268435456) =3D 0x50803c80 [errno =3D 0] >>> malloc(268435456) =3D 0x608042c0 [errno =3D 0] >>> malloc(268435456) =3D 0x70805b00 [errno =3D 0] >>> malloc(268435456) =3D 0x808063c0 [errno =3D 0] >>> malloc(268435456) =3D 0x90807580 [errno =3D 0] >>> malloc(268435456) =3D 0xa0808b40 [errno =3D 0] >>> malloc(268435456) =3D 0xb0809980 [errno =3D 0] >>> malloc(268435456) =3D 0xc080abc0 [errno =3D 0] >>> malloc(268435456) =3D 0xd080ba00 [errno =3D 0] >>> malloc(268435456) =3D 0xe080cc80 [errno =3D 0] >>> malloc(134217728) =3D 0xf080d700 [errno =3D 0] >>> malloc(67108864) =3D 0x0 [errno =3D 12] >>> malloc(33554432) =3D 0xf880eb40 [errno =3D 0] >>> malloc(16777216) =3D 0xfa80fc00 [errno =3D 0] >>> malloc(8388608) =3D 0x0 [errno =3D 12] >>> malloc(4194304) =3D 0xfb810840 [errno =3D 0] >>> malloc(2097152) =3D 0xfbc117c0 [errno =3D 0] >>> malloc(1048576) =3D 0xfbe12940 [errno =3D 0] >>> approx. total, a lower bound: 3511 MiBytes >>>=20 >>>=20 >>> Note: If the Tegra TK1 in question has more than >>> 4 GiBytes of RAM, the command line should explore >>> more than the example that I used. >>>=20 >>>=20 >>> Note: I've used the program for other patterns of >>> allocations. That is why it is not just a fixed >>> exploration algorithm. >>>=20 >>>=20 >>> As for poudriere-devel, I find it useful, even on >>> the OrangePi+ 2ed. But mostly that is a rare run >>> that is checking on how well the handling goes for >>> the 2 GiByte of RAM context (with notable SWAP for >>> the size of RAM). In other words, monitoring the >>> growth in a context that will break sooner than >>> my other contexts generally would. The tests take >>> days overall, most of the time being for rust and >>> a llvm* . >>>=20 >>> Historically I've been able to have 2 builders, >>> each with MAKE_JOBS_NUMBER_LIMIT=3D2 , so all 4 >>> cores in use building lang/rust and a devel/llvm* >>> at the same time successfully in poudriere-devel >>> on the 2 GiByte OrangePi+ 2ed. (This was before >>> recently imposing --threads=3D1 experiments, >>> given the recent build failures.) >> I should have noted that my normal devel/llvm* builds >> on aarch64 and armv7 avoid building: BE_AMDGPU and >> MLIR . They also target BE_NATIVE instead of >> BE_STANDARD . (aarch64 BE_NATIVE includes armv7 as >> well.) >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com > Tegra has 4 Cortex-A15 cores and 2 GB of RAM. OrangePi+ 2ed: Cortex-A7 with 4 cores and 2 GiBytes of RAM. I wonder if the 2483 MiBytes would end up being about the same on the Tegra variation indicated. > All ports are built with default options. The only non-standard item = is the swap size -> I have 16GB of swap on a swap partition on the SSD. Wow, 16 GiBYtes of swap space for 2 GiBytes of RAM. I guess when the swap is added that you get a notice-pair of the structure: QUOTE warning: total configured swap (. . . pages) exceeds maximum recommended = amount (. . . pages). warning: increase kern.maxswzone or reduce amount of swap. END QUOTE with a rather large difference between the two ". . ." figures. Do you make other adjustments to deal with the otherwise-reported potential mistuning? It appears to make tradeoffs in the kernel internal memory handling, if I understand right. > But I guess that's not important in this case. At least for my context, it appears that memory allocations are failing to find a big enough free area inside the process's address space --without running out of system RAM+SWAP space overall. For the OrangePi+ 2ed ( and devel/llvm18 18.1.7 ) it was during the earlier linker run for: FAILED: bin/lli-child-target=20 . . . LLVM ERROR: out of memory Allocation failed That much finished just fine on the Windows DevKit 2023 used via a armv7 jail ( devel/llvm18 18.1.8_1 ). The failure point was in a later link ( matching what I saw via devel/llvm19 ). > I just started build of llvm19 - but it takes few hours to complete.. Probably fewer hours than on the OrangePi+ 2ed but more than on the Windows DevKit 2023 (if they were completing, anyway). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Aug 5 21:35:12 2024 X-Original-To: freebsd-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 4Wd8qd67ZWz5Sl54 for ; Mon, 05 Aug 2024 21:35:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wd8qd3xGKz43Nl for ; Mon, 5 Aug 2024 21:35:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722893723; bh=LWvEYb+5MHo+I+RZHBeVptKoNfrgP5JRIN7poffxYSM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T3kpHVhvkCwgKtGTTQWVrDCx4qQc5inJ9pjb4LJJfgkHLjETZUJww29BP1VLEucpm6Vfg2TC30NR1sV+90svZc5WNT1oiveupd+PSvPkuRfbmNtec1fRuokuwlEnP5WDoDyLE5S61xmGW+R0stc4aKjRRuIt3lhvb6TRgYV+HyRm8qEhjKtxMDaaCyBm+rhcdAeTgtbhgALiecJ78J/ogi2LnChzDInwa2p/RAr889OrsEuUvKyH3vQW2MCV5hiJ5bsK6utTnkSyu6WNoKIJnUCfQ0V5Y2WxqPz1QCp926zVhlKua9TBB32Zo5Z68nDxK5v2lkRMvw6qfE5CV1DPLg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722893723; bh=LfHlseS58GF3yKiSt7W9f5vqY+tSwRoOkSo8jjTOuh3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U7fkvJmV0oHnHm0cmu8rCpQE89ceJ7ffsbHnzczRJmGwUFF/ipxNVDIykTtfodqfhFMD8KWDMzOLh8m9Y2ZuoHot2OOkYg09Ylz7mO/bSFk9QsW8BQ04+6TrL+Zk3jMdgZPOXDKF11sHN11tacHCCVSYmb0fxU+cBELz5xSlhCEuhiYLHW80uPc/Xji5Njk1jg8QQqC732Sy2z4lwVWxuvYglzpnaTXJBO491uQMlhYXsnVVlUd2pC+hoD/0B2OvsgJ5XpycOq62jflgp27zmFR6yKb5IFVdMKfX8KqAddpWGVx2SdF1Ev/lTEerTIGMCBDzfmB5Tw2QJ/wJ0H/jUg== X-YMail-OSG: O71Mk1QVM1n7_ZEB5qe1sUJ3q0.ugXIyThXgnw0SHGXO6yWpD7Pc4q43UOQeGcz F.kzdANCSsCzmPmFO1JVJYyeGyZAzzRrLa.bcEmQ4AVLsztlgGFOtMqk1mV6xq_aSyHRutkODbCS eEiVCtHTwASS7JGFTiYIdrCwh5eHYS93e_B9IhUDNXeJsepKWSPl6ItqZP80wzybWqyQvkhgxfVQ SZM6ZVxQh6BNtj_0HoDrSr_2p_UiMDb5V03Piyo0xqyfRdDhZloA3mXI85g07nsHRLT5PrUKpvDm QqOhbNX85bs6AKdLTv4exymsrjRaK63r71I2kq8v5HKtnzTyvzqLcfDwV12xm6SnyVAIzluX5mBv MGEV03x9OUPJMsJbu.q8dfU9oP5NfoMXnG0ePVDj8pW6zSIokjjORpYh_cvx8LAnel4EEwpF5bLz PvAcLV9NcD5QtRQpHscHpkVvdzmgI_KsOMpt0lkByUIFWe_ynMj._5n_X5s_P80_8N7NBGUeYAi7 Pilx_x9BmYlsqzfXET7X6b9_OfXSfA_nXbTuyaUFBjZLwge00vKXbvcjqMkmz68Nx.rDIHoPkh6N 33IumIThU2gsk.896yBssYD_zOYEc8ZaitfiUfp204wfLQSDwlQJxCOWg8pX6PzVua2KLo07yjlL 1q_.sPE.4xG9S_x4DltD.M8nf0nUtswUYc2MX46BY9q5rWnQPlNNxX4BZfo6U_KdX8iD4.l7kV2n ZUo_ZmpSfmBna4.2ggq66vIAjkawxXcdAZMsXbsaS9aGN6Xmdc65t_SBt8GCrq4Xy5CbdDt72Fso 6fzfFu9jbL4LeV45L7GMeMgCC1ziroQqR99dnoi_oxgcBPPOyavHRJ_qxsN5I4U0LKs.R3ctbbSR s8hVtGRSSTGDmFc7UqcQbVt69vWjchxt8DUKpr0uo_8a_JMoyGlz.D1sfy4eBDWHkCKN4yr3KO0H 0EdFVu6Ldvz9JYHxztkuH8SvDxiyOEIHkVGKBs2Wi_mkl.RxSaxHU1D5Naj7zLvfGJpEcwR3QCh7 4bMRn4iAjBkxEa2WytDPE.wi5kfS4cwSuwdtkWr1.RCPNFypoYHuiQMQivMQ7uCi0grm7Z_xSizT f_UlSvYO5fTc.MYo6d353SsCCvtie5Bqa0EyAhUkv6pV1eOOgpERqPYONSIbD9JTua06YvZILH1B UVgnb1HbvyP8w_7e3vsEBdcr0QC97DwIWmwzaDJCXKg68omqYQKscNKgcW_7itl6hGSqeauH0LsA mw9qJzL7o5tdoRJq2fY2IjMmgFgbaDOd.Gg3K8Ujnn6Kln69pfKJHZVVZ5keC5ZCPb3xrkbI9cNL 3q7RpshsYaVJCJxKLY4WX5jaiHDObq9Pm1Xueerrosyi52HKHYKyK_kdiaAOci_gvp0DHKhnXiHG A8yXkPw6pXLl522XTbnYdEgVIUke8EQYShV2qxlW7vEhCxdua3SFF3Vo3b1KrftYDbAFgn6D_Xyi k7mso1TAZHLHvQ42IGFLJhtFUjk3RZGLXV9Hvuru_a9GfYTC1LDLQ2iMtFeDRUoIWvkfV9EHRhME r8U_iTKnJDdsMByN91ybFZmJUJIA6SH7_5RRTBGwef6RjOGj7ZBhItiSkl6tEups0xkRMG_p9Yl3 CwT_AdTH8inMUX6fEQO95nZVTJdBwXmhLARUNQFP6E58qJDHyuYlZU0hbNdPvUUP0BWx.WvgYM.K nypkzPJPgTJW5UOtm.vjG4YFmmm0W8lQih7hfeDvS7KndRJWQ.SxcsBj9nz6b5Vp7iW_1QKxWwPA fTXW3WUzciapjpXvUzCkmT.baCUo53RcUBcDrIoKI_YSMSFVfFPfHK.D9CxwI17qDTMDwjieYXHt OSx0iAeL6daQ825CGfPBfWx3bDTclSPwkUFIfxr._Ga0aBUQDn02R0KxcAAo6s1P5dedINgTcgt0 4HYNwhpQXCwYT9mlSce3cxCmXrpNteJ9KFZCYrENDIDB1KrzC0Qq817uKNf9KLiB0mbEVINbA.yx YvF4r.ZAPtiK.Wc2Lhes9mfZteEDALZicl0o19IlLhNU.j2KeT2BJDhf2HPuScJYCH.thuWTqz8o e6zNhto7CmjsuV0JAlwU6ga85i19Uxz5V3HebFVy1jlK8mD1KYVckKprOC1rvyDDsKDLyWoMocWF U4wtDq8xR3jeqgD._jGQcNMxZTjwk.vAfF6e6.y.YJou2nNjjPlBzdCQX5DldmeW2Xch_vPzcTZr F8VUTd8FpxoEd.2o4FH_FztA4q1PukZ4AckTOWPTisL2H2iISP5au_h.NzRmBbnYuyl8aiTqvAdJ ncABVNAX6xABbknrH3T.DJI0_JvubMzjUCESAo1HjLNj. X-Sonic-MF: X-Sonic-ID: ad507096-afb7-4400-b266-9ddd2c5f7428 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 21:35:23 +0000 Received: by hermes--production-gq1-5d95dc458-kk28l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 613fd945f2f80815bc67accffec30e46; Mon, 05 Aug 2024 21:35:23 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: <4b5a6fa1-3b08-4b8b-8577-c548116d2115@freebsd.org> Date: Mon, 5 Aug 2024 14:35:12 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> <0b3b532c-ae94-439c-81aa-9e80a08af43f@freebsd.org> <4b5a6fa1-3b08-4b8b-8577-c548116d2115@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Wd8qd3xGKz43Nl On Aug 5, 2024, at 08:57, meloun.michal@gmail.com wrote: > On 05.08.2024 11:09, Mark Millard wrote: >> On Aug 5, 2024, at 00:44, meloun.michal@gmail.com wrote: >>>> . . . >>> Tegra has 4 Cortex-A15 cores and 2 GB of RAM. >> OrangePi+ 2ed: Cortex-A7 with 4 cores and 2 GiBytes of RAM. >> I wonder if the 2483 MiBytes would end up being about the >> same on the Tegra variation indicated. >=20 > Yep, it must be +/-same. The 2/2 GB for userland/kernel is defined by = HW. Only size of shared libraries may affect (lower) usable user space = for given program. >>> All ports are built with default options. The only non-standard item = is the swap size -> I have 16GB of swap on a swap partition on the SSD. >> Wow, 16 GiBYtes of swap space for 2 GiBytes of RAM. I guess >> when the swap is added that you get a notice-pair of the >> structure: >> QUOTE >> warning: total configured swap (. . . pages) exceeds maximum = recommended amount (. . . pages). >> warning: increase kern.maxswzone or reduce amount of swap. >> END QUOTE >> with a rather large difference between the two ". . ." figures. >> Do you make other adjustments to deal with the otherwise-reported >> potential mistuning? It appears to make tradeoffs in the kernel >> internal memory handling, if I understand right. > The above message should be interpreted as: warning, the kernel may in = word, rear case need to allocate additional > memory when swapping some object(memory) out. This may leads to = deadlock/panic. But again, event is this warning valid, > resulting deadlock/panic is very rare. I newer see it in past many = years... Interesting. >>> But I guess that's not important in this case. >> At least for my context, it appears that memory allocations >> are failing to find a big enough free area inside the >> process's address space --without running out of system >> RAM+SWAP space overall. >> For the OrangePi+ 2ed ( and devel/llvm18 18.1.7 ) it was >> during the earlier linker run for: >> FAILED: bin/lli-child-target >> . . . >> LLVM ERROR: out of memory >> Allocation failed >> That much finished just fine on the Windows DevKit >> 2023 used via a armv7 jail ( devel/llvm18 18.1.8_1 ). >> The failure point was in a later link ( matching what >> I saw via devel/llvm19 ). >>> I just started build of llvm19 - but it takes few hours to = complete.. >> Probably fewer hours than on the OrangePi+ 2ed but >> more than on the Windows DevKit 2023 (if they were >> completing, anyway). >=20 > The native build is still running (60% in fact), arm32 jail build has = been stopped on my Honeycomb (killed by OOM).Unfortunately this is an = old problem and is common on all platforms. The current LLVM cannot be = built without additional tricks on machines that have less than 2GB (RAM = + swap) per core..... FYI: A small RAM+SWAP test for amd64-as-amd64 for devel/llvm18 18.1.7 . = . . USE_TMPFS=3Dno Targetting BE_NATIVE without BE_AMDGPU and without MLIR. Avoiding being = stripped. (MLIR is resource and time expensive to build but I make no use of it.) (I also make no use of BE_AMDGPU materials.) (I've not been doing any cross builds in a very long time.) (Not stripping can make for better failure reporting.) (Leading whitespace might notn b e preserved in the copy of the diff:) # git -C /usr/ports/ diff devel/llvm18 diff --git a/devel/llvm18/Makefile b/devel/llvm18/Makefile index 1b1f759ba50e..779ddf3bea7e 100644 --- a/devel/llvm18/Makefile +++ b/devel/llvm18/Makefile @@ -87,7 +87,7 @@ CMAKE_ARGS+=3D -DLLVM_ENABLE_TERMINFO=3DOFF CMAKE_ARGS+=3D -DLLVM_VERSION_SUFFIX=3D OPTIONS_DEFINE=3D BE_AMDGPU BE_WASM CLANG COMPILER_RT DOCS LLD = STATIC_LIBS -OPTIONS_DEFAULT=3D BE_AMDGPU BE_WASM CLANG LLD +OPTIONS_DEFAULT=3D BE_WASM CLANG LLD OPTIONS_SINGLE=3D BACKENDS OPTIONS_SINGLE_BACKENDS=3DBE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_EXCLUDE_armv6=3D COMPILER_RT @@ -103,7 +103,7 @@ OPTIONS_DEFINE_powerpc=3D GOLD OPTIONS_DEFINE_powerpc64=3D GOLD OPTIONS_DEFINE_powerpc64le=3D GOLD -OPTIONS_DEFAULT+=3D BE_STANDARD COMPILER_RT EXTRAS LIT LLDB MLIR = OPENMP \ +OPTIONS_DEFAULT+=3D BE_NATIVE COMPILER_RT EXTRAS LIT LLDB OPENMP \ PYCLANG POLLY STATIC_LIBS OPTIONS_DEFAULT_amd64=3D GOLD OPTIONS_DEFAULT_powerpc=3D GOLD @@ -211,8 +211,8 @@ CONFLICTS_INSTALL=3D ${PORTNAME}${LLVM_SUFFIX} = ${PORTNAME}${LLVM_SUFFIX}-lite .if defined(WITH_DEBUG) CMAKE_BUILD_TYPE=3D RelWithDebInfo -STRIP=3D .endif +STRIP=3D PLIST_SUB+=3D LLVM_MAJOR_MINOR=3D${LLVM_MAJOR_MINOR} \ LLVM_MAJOR=3D${LLVM_MAJOR} \ @@ -224,10 +224,10 @@ FIRST_COMMAND=3D = ${COMMANDS:C/^/XXXX/1:MXXXX*:C/^XXXX//} MAN1SRCS+=3D ${LLVM_MAN1SRCS} -STRIP_LIBS=3D BugpointPasses.so \ - LLVMHello.so \ - ${LIBNAME}.0 \ - libLTO.so +#STRIP_LIBS=3D BugpointPasses.so \ +# LLVMHello.so \ +# ${LIBNAME}.0 \ +# libLTO.so EXTRAS_LIBS=3D \ libclangApplyReplacements \ Note: This amd64 testing is not using --threads=3D1 for linking. A Hyper-V context for amd64-as-amd64 set up for small memory testing = with 4 Hyper-V cores: real memory =3D 2147483648 (2048 MB) avail memory =3D 2029309952 (1935 MB) Swap: 3584Mi Total So: AVAIL_RAM+SWAP =3D=3D 5519 MiBytes Building just llvm18-18.1.7 : [00:00:22] [01] [00:00:00] Building devel/llvm18@default | = llvm18-18.1.7 [00:55:27] [01] [00:55:05] Finished devel/llvm18@default | = llvm18-18.1.7: Success ending TMPFS: 0.00 GiB (My poudriere-devel is patched to report the ending TMPFS figures.) =46rom my patched-up top's output from monitoring during the build: Mem: . . . , 1462Mi MaxObsActive, 582432Ki MaxObsWired, = 1940Mi MaxObs(Act+Wir+Lndry) Swap: 3584Mi Total , . . . , 1090Mi MaxObsUsed, 2455Mi = MaxObs(Act+Lndry+SwapUsed), 2995Mi MaxObs(A+Wir+L+SU), 2996Mi (A+W+L+SU+InAct) So, slightly under 3 GiBytes RAM+SWAP observed as used, well under 8 = GiBytes. 3GiByte[RAM+SWAP]/4Core =3D=3D 0.75 GiByte[RAM+SWAP]/Core, well under 2 = GiByte[RAM+SWAP]/Core. =46rom this and the like of your OOM reporting, I get an idea how much = MLIR, BE_AMDGPU, and BE_STANDARD contribute to the RAM+SWAP use. (I've = not tested such directly in a long time.) For reference: # uname -apKU FreeBSD 7950X3D-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #144 = main-n271413-1f7df7570174-dirty: Sat Jul 27 16:01:52 UTC 2024 = root@7950X3D-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64= .amd64/sys/GENERIC-NODBG amd64 amd64 1500021 1500021 # ~/fbsd-based-on-what-commit.sh -C /usr/main-src 1f7df7570174 (HEAD -> main, freebsd/main, freebsd/HEAD) LinuxKPI: move = __kmalloc from slab.h to slab.c Author: Bjoern A. Zeeb Commit: Bjoern A. Zeeb CommitDate: 2024-07-26 11:51:04 +0000 branch: main merge-base: 1f7df757017404011732196e65981d9325f7a89f merge-base: CommitDate: 2024-07-26 11:51:04 +0000 n271413 (--first-parent --count for merge-base) # ~/fbsd-based-on-what-commit.sh -C /usr/ports 4e0616a2066d (HEAD -> main, freebsd/main, freebsd/HEAD) = graphics/libavif: drop maintainership Author: Jan Beich Commit: Jan Beich CommitDate: 2024-07-13 01:31:18 +0000 branch: main merge-base: 4e0616a2066dc9e45cef47de812efdea4e09709c merge-base: CommitDate: 2024-07-13 01:31:18 +0000 n671165 (--first-parent --count for merge-base) Note: This /usr/ports/ is from before devel/llvm19 or = /devel/freebsd-gcc14 . I've not synchronized this UFS environment with = my experimention with a more recent ports vintage. devel/llvm18 is at = 18.1.7 still here. Hyper-V is actually using the same UFS boot media as the native UFS = FreeBSD boot does --but is using a smaller swap partition. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Aug 6 18:27:21 2024 X-Original-To: freebsd-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 4WdhcS6Zjbz5SQfl for ; Tue, 06 Aug 2024 18:27:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WdhcS335Tz4Dy7 for ; Tue, 6 Aug 2024 18:27:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722968854; bh=9Hu8Ar0omMFoTuxDvH8Fk2FI2RtioRzPbUxIfUnaKJ8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ty0JWSKqNX7Dgdf8rlPcyEovMLXGBwzwjHbRR2G/vkYvAp/4wluiZ7ukLMPWp6uQuVbLqHILprKGqt8DSCYYbWy0lZAjlK9XlpbOCQg5nMvc3dtQs6FV0x+OZA0C7Z1Q3UO6WIgNPFORDITFxycJUonTk5f5yOBeek7xuqDClLCvpiVod60Ak3irCnYUh3AJ3amz1WOTNUgPgp5xiYV9Nx4lTSKweiAOxevTfZf/zatXJ+7naJ15dwItnBnBOXIoc44hf1QSjsB14U2IiF7S3Ji+qGdZmrPfx87MEJQjn4iMxvW/EZVSmty99HYKVcyiH+qEF1lUq7lTRf/qgNamDQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722968854; bh=kaIb9WIBubi2S6vwH2BQhEWLzI3gawyZSmo5n2ySwMj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Jf4q3FhclBvlT/nqxukE3zNEHztvP29Q/6a0ANm7Tv8hP2GcddnADPlqYKMDbfhRwXr1E9lFdY6RSY6FxUXmM/OtTm8TFtFz52/4HAYOqtyFr/Q2YeH1BDZqDcM3MNmdvs2w2gHKU1HTOE7bF1uEoteZTE7CahYBv98uOrVcR14myJchkssG5RTOspnLZ6De7y/vKo409OHhPccmQPxjbUNjA5GSI849tWB3EcSEK1XksJlb9ZIQH8lzXYGNtLkQ/PmOdaLmfOB4WwUn2oh6BpvkgRsEqlYBBOiFQTYQma2CrooSh2kPwf4Towp5gVRQC0YT4OlzTF4nHxMDL61aRw== X-YMail-OSG: NC8kTDcVM1kTP42JePbSkFJ4nllcY6ZKCHyckCIVauBaGZvUeH0J_iS_aXNahga ataoXDE_u5OXsjUdpXJ4RN8_EvWLX5xq8JCl1CATP1dw_dZPlcDILI6TmKZ4R9JymtvXSt5Y6YQp lLT__6F318BHaKHSTk0GbX6RPy9qSogWigvb39H8dB33DkRf5u73._ooo5ThgTBcb4Ga.flP5x5s 5sxzhVHwC8RazKqUDyinKuhiYg8uysSkmHZ.w0UXHRvOvif2qwd6gVvg8G7q4YPX12AP2hGllpyd vhnj_PyUz52.7Z92c8764yjw_KauRJXPcFD0jS._nT1ToMWqMHioFcbUN.PAYCyOJcDwzehEoFOr MVW7ifnuT8OARsUfZM5kmV.eq.JPsjooTDf6JKriHKgA3mrwP3qWpz5_OoiQOAZfOFDignRQ_uES Bx2.9DeOZf_WueC68S.Kw5i6z5keg9SEansvoMZ3LVaJG9mHNc.ElDv.MRUd_8wGHReF_uBsvuU8 R6yWooQK4ODL_1VczTjJVBkjQ0tXwjrgE72wWeyWb9SwDNM9tEk.FhjKRfGksUNp5j1md66rX_8r j4AEhjXDojHxkN5ipePq.YOmm1ABz6Fg6Es2FukumH_EakgZPMjNUYXgH1vHSV3.kmZOC840daqI esQWMBIS2onKvMWk2UhmZgzAUhObBGOreOnTN6qj2lxoX6NhEspNXsD2FhDpBsZaAq__XnUkjeu0 eDAV1duIrVWfZd2h3d7nXcm709U.dizaKHbbEk5jPs1ZP6nLq8Bk8DKuh1uZsOA6E1Ra0Bv5i5dn yhpSww5MLi83z.NWMZ7NbB_Tmyq25Qr8bCTbuqERieVTRIhSWdjD44kxGOffHHEA7g8IrTl0sOXa aW7UzWIpWQaYstOyLdJTFVaMCD04m2ZSZeXqLjgoxFBLA1IquYpOjYJuYXpbsMx71ilhTuwOqKci Gj_WCI1vkup4etSNv8p35R.zF8uxDb0iZLb7e1nNxV9AYW.Q_s6NOl6qyEbZ_JAMbks7A0kipHZr Mh3ZfpNLFi28A1ARnXxlghPGSctbEhtFn7c7LybmNCcwyzbZOWSxCiHgrikO7hOJQG.31qpyhtAE A4aTXsScWHWqpKaybMmb.zOoHehc5SqAhb2HKcvqLyvM9w0elaU.iSJhP8V_BYi3Dz1X64aMQUYk pru.rYv5jjBocxQRv4x4vuR8P_ZuwTYVkABvsO0uHofPyd36TYVxf_K4k5tzDQdNqNZ4wZwGOZT_ X6_b8RGUxiUI1cFFOg9rncEOz9bhCwTIG1ITNHn8Odrh8ZQoSCL3hAVmso0eEU_LKNX5qhIkEK6T I9xeu0sP3Iz1n.SJO9wkhqV3guQl.6tCftyrAabbaZ1dToJrAn.67aSevXF2eqy03MIkZn.FmwgC 3FrMuFvr6Yz4K0ANIgEwzM_lcg160DTALEUuyeObT3zxivZOfnJcgRlZ1ipOW_baNAMrds2d5J4h dryrxOxg5lmXb_Q3t_mRkbPQm7CKpl6ie6DHi9neGaxBtXxrEIXkR7SmU3oJKoGNdBRGNW6cXuRn o0phmE2iMFR05E949RFqzgNxQkKH533gLJpXyOook_IGcRrDuil0apNcwbS5g8NPLFI8bnbx_.Oj NGd7oV_Szmrncir2QRHd9xUSaAuLPcOTdOEfFMeAlPVQOtwQh7f8hvmD5v8CC6nucamg9chPsJaL jU9wgvH80ivvgQSVJV1WvkGgRG717_8ndSuPYjfKRifp0gMbaqs63MDz1H5PPG25SRXhS2zYmPon rbUyrFLKgI3XMOlvaTt6c1.0rBtMg8toceg58yO8GLEQv.DyIl7Av03wh5zBCjm3p6BdAXaPTt.W .hQoGMWzf45TBaz0KNnl34qVH3XpjeXnWqmdgXVjZfQw4TIurigSX.sLfAJ9EsMds.becOgXDN9A O9ICOXKbixyDTF_XHrm1EOJwSwvFm7Rgj1CfvQsRoLGQgwIQ_Jm9gfWmfYslKjKrKERLyyMLteDa qt6_3FNPZwUoQqjZZM0ngGDWZOks1tozQJCmyN15PGQWNjFDtk7SOuhs9m80GF1.GsuZK1byiOas 60TEtWNinW6bxYAWkNaAVx1kL2lVXrZqBvwRa79P2uk3A7.I9nUlHZQZRmDuGCfofvV.QwLJkwjF euxjfNomssxN11JocpxqZwKAE51R_YgkzJxuu9e0rp_jLGzNmVUUaMt3saJ1.6TcDtW8bbr.GLt. TlBob.ByCpNdevJBP3eh16ZoiMzZfdff9mUBRvvdXnx8fSz7dE6bGU1ZVQTiScDQxN9iX41nbT46 88eoqaXklE_QmbtDIGRHZLuyBF9cKh_vwI9Cana8- X-Sonic-MF: X-Sonic-ID: e8f3a3cd-1f1e-48bf-9ee9-d5483f2998aa Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Tue, 6 Aug 2024 18:27:34 +0000 Received: by hermes--production-gq1-5d95dc458-sd55t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd1eb19ea6e3a30f65d9732d71d41076; Tue, 06 Aug 2024 18:27:31 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: <0853529b-eb45-43c7-9957-8fe23001c94a@freebsd.org> Date: Tue, 6 Aug 2024 11:27:21 -0700 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <0C648446-D075-4981-B348-1525DD1ECD8A@yahoo.com> References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> <0b3b532c-ae94-439c-81aa-9e80a08af43f@freebsd.org> <4b5a6fa1-3b08-4b8b-8577-c548116d2115@freebsd.org> <0853529b-eb45-43c7-9957-8fe23001c94a@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4WdhcS335Tz4Dy7 On Aug 6, 2024, at 01:56, meloun.michal@gmail.com wrote: > On 05.08.2024 23:35, Mark Millard wrote: >> On Aug 5, 2024, at 08:57, meloun.michal@gmail.com wrote: >>> On 05.08.2024 11:09, Mark Millard wrote: >>>> On Aug 5, 2024, at 00:44, meloun.michal@gmail.com wrote: >>>>>> . . . >>>>> Tegra has 4 Cortex-A15 cores and 2 GB of RAM. >>>> OrangePi+ 2ed: Cortex-A7 with 4 cores and 2 GiBytes of RAM. >>>> I wonder if the 2483 MiBytes would end up being about the >>>> same on the Tegra variation indicated. >>>=20 >>> Yep, it must be +/-same. The 2/2 GB for userland/kernel is defined = by HW. Only size of shared libraries may affect (lower) usable user = space for given program. >>>>> All ports are built with default options. The only non-standard = item is the swap size -> I have 16GB of swap on a swap partition on the = SSD. >>>> Wow, 16 GiBYtes of swap space for 2 GiBytes of RAM. I guess >>>> when the swap is added that you get a notice-pair of the >>>> structure: >>>> QUOTE >>>> warning: total configured swap (. . . pages) exceeds maximum = recommended amount (. . . pages). >>>> warning: increase kern.maxswzone or reduce amount of swap. >>>> END QUOTE >>>> with a rather large difference between the two ". . ." figures. >>>> Do you make other adjustments to deal with the otherwise-reported >>>> potential mistuning? It appears to make tradeoffs in the kernel >>>> internal memory handling, if I understand right. >>> The above message should be interpreted as: warning, the kernel may = in word, rear case need to allocate additional >>> memory when swapping some object(memory) out. This may leads to = deadlock/panic. But again, event is this warning valid, >>> resulting deadlock/panic is very rare. I newer see it in past many = years... >> Interesting. >>>>> But I guess that's not important in this case. >>>> At least for my context, it appears that memory allocations >>>> are failing to find a big enough free area inside the >>>> process's address space --without running out of system >>>> RAM+SWAP space overall. >>>> For the OrangePi+ 2ed ( and devel/llvm18 18.1.7 ) it was >>>> during the earlier linker run for: >>>> FAILED: bin/lli-child-target >>>> . . . >>>> LLVM ERROR: out of memory >>>> Allocation failed >>>> That much finished just fine on the Windows DevKit >>>> 2023 used via a armv7 jail ( devel/llvm18 18.1.8_1 ). >>>> The failure point was in a later link ( matching what >>>> I saw via devel/llvm19 ). >>>>> I just started build of llvm19 - but it takes few hours to = complete.. >>>> Probably fewer hours than on the OrangePi+ 2ed but >>>> more than on the Windows DevKit 2023 (if they were >>>> completing, anyway). >>>=20 >>> The native build is still running (60% in fact), arm32 jail build = has been stopped on my Honeycomb (killed by OOM).Unfortunately this is = an old problem and is common on all platforms. The current LLVM cannot = be built without additional tricks on machines that have less than 2GB = (RAM + swap) per core..... >> FYI: A small RAM+SWAP test for amd64-as-amd64 for devel/llvm18 18.1.7 = . . . >> USE_TMPFS=3Dno >> Targetting BE_NATIVE without BE_AMDGPU and without MLIR. Avoiding = being stripped. >> (MLIR is resource and time expensive to build but I make no use of = it.) >> (I also make no use of BE_AMDGPU materials.) >> (I've not been doing any cross builds in a very long time.) >> (Not stripping can make for better failure reporting.) >> (Leading whitespace might notn b e preserved in the copy of the = diff:) >> # git -C /usr/ports/ diff devel/llvm18 >> diff --git a/devel/llvm18/Makefile b/devel/llvm18/Makefile >> index 1b1f759ba50e..779ddf3bea7e 100644 >> --- a/devel/llvm18/Makefile >> +++ b/devel/llvm18/Makefile >> @@ -87,7 +87,7 @@ CMAKE_ARGS+=3D -DLLVM_ENABLE_TERMINFO=3DOFF >> CMAKE_ARGS+=3D -DLLVM_VERSION_SUFFIX=3D >> OPTIONS_DEFINE=3D BE_AMDGPU BE_WASM CLANG COMPILER_RT DOCS = LLD STATIC_LIBS >> -OPTIONS_DEFAULT=3D BE_AMDGPU BE_WASM CLANG LLD >> +OPTIONS_DEFAULT=3D BE_WASM CLANG LLD >> OPTIONS_SINGLE=3D BACKENDS >> OPTIONS_SINGLE_BACKENDS=3DBE_FREEBSD BE_NATIVE BE_STANDARD >> OPTIONS_EXCLUDE_armv6=3D COMPILER_RT >> @@ -103,7 +103,7 @@ OPTIONS_DEFINE_powerpc=3D GOLD >> OPTIONS_DEFINE_powerpc64=3D GOLD >> OPTIONS_DEFINE_powerpc64le=3D GOLD >> -OPTIONS_DEFAULT+=3D BE_STANDARD COMPILER_RT EXTRAS LIT LLDB = MLIR OPENMP \ >> +OPTIONS_DEFAULT+=3D BE_NATIVE COMPILER_RT EXTRAS LIT LLDB = OPENMP \ >> PYCLANG POLLY STATIC_LIBS >> OPTIONS_DEFAULT_amd64=3D GOLD >> OPTIONS_DEFAULT_powerpc=3D GOLD >> @@ -211,8 +211,8 @@ CONFLICTS_INSTALL=3D ${PORTNAME}${LLVM_SUFFIX} = ${PORTNAME}${LLVM_SUFFIX}-lite >> .if defined(WITH_DEBUG) >> CMAKE_BUILD_TYPE=3D RelWithDebInfo >> -STRIP=3D >> .endif >> +STRIP=3D >> PLIST_SUB+=3D LLVM_MAJOR_MINOR=3D${LLVM_MAJOR_MINOR} \ >> LLVM_MAJOR=3D${LLVM_MAJOR} \ >> @@ -224,10 +224,10 @@ FIRST_COMMAND=3D = ${COMMANDS:C/^/XXXX/1:MXXXX*:C/^XXXX//} >> MAN1SRCS+=3D ${LLVM_MAN1SRCS} >> -STRIP_LIBS=3D BugpointPasses.so \ >> - LLVMHello.so \ >> - ${LIBNAME}.0 \ >> - libLTO.so >> +#STRIP_LIBS=3D BugpointPasses.so \ >> +# LLVMHello.so \ >> +# ${LIBNAME}.0 \ >> +# libLTO.so >> EXTRAS_LIBS=3D \ >> libclangApplyReplacements \ >> Note: This amd64 testing is not using --threads=3D1 for linking. >> A Hyper-V context for amd64-as-amd64 set up for small memory testing = with 4 Hyper-V cores: >> real memory =3D 2147483648 (2048 MB) >> avail memory =3D 2029309952 (1935 MB) >> Swap: 3584Mi Total >> So: AVAIL_RAM+SWAP =3D=3D 5519 MiBytes >> Building just llvm18-18.1.7 : >> [00:00:22] [01] [00:00:00] Building devel/llvm18@default | = llvm18-18.1.7 >> [00:55:27] [01] [00:55:05] Finished devel/llvm18@default | = llvm18-18.1.7: Success ending TMPFS: 0.00 GiB >> (My poudriere-devel is patched to report the ending TMPFS figures.) >> =46rom my patched-up top's output from monitoring during the build: >> Mem: . . . , 1462Mi MaxObsActive, 582432Ki = MaxObsWired, 1940Mi MaxObs(Act+Wir+Lndry) >> Swap: 3584Mi Total , . . . , 1090Mi MaxObsUsed, 2455Mi = MaxObs(Act+Lndry+SwapUsed), 2995Mi MaxObs(A+Wir+L+SU), >> 2996Mi (A+W+L+SU+InAct) >> So, slightly under 3 GiBytes RAM+SWAP observed as used, well under 8 = GiBytes. >> 3GiByte[RAM+SWAP]/4Core =3D=3D 0.75 GiByte[RAM+SWAP]/Core, well under = 2 GiByte[RAM+SWAP]/Core. >> =46rom this and the like of your OOM reporting, I get an idea how = much MLIR, BE_AMDGPU, and BE_STANDARD contribute to the RAM+SWAP use. = (I've not tested such directly in a long time.) >> For reference: >> # uname -apKU >> FreeBSD 7950X3D-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #144 = main-n271413-1f7df7570174-dirty: Sat Jul 27 16:01:52 UTC 2024 = root@7950X3D-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64= .amd64/sys/GENERIC-NODBG amd64 amd64 1500021 1500021 >> # ~/fbsd-based-on-what-commit.sh -C /usr/main-src >> 1f7df7570174 (HEAD -> main, freebsd/main, freebsd/HEAD) LinuxKPI: = move __kmalloc from slab.h to slab.c >> Author: Bjoern A. Zeeb >> Commit: Bjoern A. Zeeb >> CommitDate: 2024-07-26 11:51:04 +0000 >> branch: main >> merge-base: 1f7df757017404011732196e65981d9325f7a89f >> merge-base: CommitDate: 2024-07-26 11:51:04 +0000 >> n271413 (--first-parent --count for merge-base) >> # ~/fbsd-based-on-what-commit.sh -C /usr/ports >> 4e0616a2066d (HEAD -> main, freebsd/main, freebsd/HEAD) = graphics/libavif: drop maintainership >> Author: Jan Beich >> Commit: Jan Beich >> CommitDate: 2024-07-13 01:31:18 +0000 >> branch: main >> merge-base: 4e0616a2066dc9e45cef47de812efdea4e09709c >> merge-base: CommitDate: 2024-07-13 01:31:18 +0000 >> n671165 (--first-parent --count for merge-base) >> Note: This /usr/ports/ is from before devel/llvm19 or = /devel/freebsd-gcc14 . I've not synchronized this UFS environment with = my experimention with a more recent ports vintage. devel/llvm18 is at = 18.1.7 still here. >> Hyper-V is actually using the same UFS boot media as the native UFS = FreeBSD boot does --but is using a smaller swap partition. >=20 > So, I'm finally able to build llvm19, on native armv7 and also on = arm32 jail. > First It needs the not yet promoted patch >=20 > https://www.mail-archive.com/lldb-commits@lists.llvm.org/msg95950.html Good to know to expect that. Thanks. > But the more serious problem is that llvm's memory requirements are = out of control. > llvm ports with default configuration causes OOM on a 4-core armv7 = with 4G RAM/16G swap, on a 4-core aarch64 with 4G RAM/16G swap and on a = 16-core aarch64 with 16G RAM/16G swap. > It's very hard to name this as correct/expected behavior. (Added dim@ = just FYI). As I understand it, the primary purpose of OPTIONS_DEFAULT is to produce the set of packages intended to be published via the package mirrors that contribute to https://pkg.freebsd.org/ . So, for example, if any such item for a platform is to involve MLIR from a devel/llvm* then that devel/llvm* needs to have MLIR in OPTIONS_DEFAULT for that platform. (MLIR is just an example here, but is a good one.) As far as I can tell, there is no implication that folks building their own packages (or just ports) should build with, for example, MLIR unless a dependency involved requires such. Going the other way, I do not see a reason to require all port options to be "cheap enough" for general use for most everyone that builds packages or ports. So, if the build servers used to populate https://pkg.freebsd.org/ mirrors build what OPTIONS_DEFAULT indicates without OOM activity problems, for example, that is all that is required relative to OPTIONS_DEFAULT and OOM as far as I can tell. This might mean that devel/llvm19 for armv7, for example, needs to not have MLIR in OPTIONS_DEFAULT if the ampere* servers can not build devel/llvm19 for armv7 when MLIR is included. But it would appear that the 64-bit platforms are likely okay with MLIR included as long as there are other packages (or FLANG use) dependent on MLIR that are intended to be supplied as well. Such contributes to why I tailor the OPTIONS_DEFAULT for the devel/llvm* that I use (and, so, build) to avoid the likes of=20 MLIR (that I do not use but has non-trivial consequences if it is built): I do not expect the OPTIONS_DEFAULT's in the ports git repository to happen to be appropriate for my context when I run into some property that does not fit my context. > Mark, I think that root case of your problems is that you're trying to = link with libraries (shared or local) with debug information = (unstriped). Seems likely that more needs to be stripped (or never generated) than before. I'll probably manage to regenerate the armv7 context and test that at some point. It is definitely true that I've historically kept more of such information around than FreeBSD does on its own for optimized code: with symbols or debug information. But it seems that such no longer fits in the armv7 context for what I've historically done. > This causes a huge memory consumption. I don't remember if it just = wastes address space (because mmapping a large library but never = accessing the debugging information) or if it accessing the debugging = information (so the link needs physical memory for it as well). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Aug 7 11:10:07 2024 X-Original-To: freebsd-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 4Wf6sX2Phzz5Rvtj for ; Wed, 07 Aug 2024 11:10:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wf6sV5yTFz4VCW for ; Wed, 7 Aug 2024 11:10:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Jje31uS5; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1723029020; bh=Pp4Ioj+BitSWlMBV8+p8tVIyoOFDrQYKEy6NABNj8ao=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Jje31uS5FLLF+naxsc0rJD3JZyaiwFP/prFj3uBLAdgvryWGc8s+iA3KDymuPABCNhg0HWTGFs2usLSRAGIjkWuLbhi2crPLtY20vtVDWBFPtkrZA2/wbhotQ2rX/2mykxWAYfEQGN1V5CnMbAaWt71mPZ7SAbbejTEaU3vrHn0kyqKvwgwhrNlLcA91voB04Hzo17FZNiuW1QuaLQ+SULO7IY8W3+j27UbujTqz3fdsnORXR+PutJaKVKf6mDBrq4sk30/zP4X9g6ckCqJ4ApTbvzdjzsXqbEqBjxSPLefqp+DmcZ4cBweOZBxS2+lPDqSMJlcZDDxiqBzynhxy+A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1723029020; bh=Zl2UxpOWk3sGTyp7fERnonoCKuEB8mkfuxNg6Bb/nTA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=kq3JRxSpPOcEBCgRLu8/sVLpabCStwHygF8zozCt7HkHurrG6Na4onSsgz8OSBwdVPup8Qmlj1pPg9Ay8Q6BSfEKSSkKLKeMhKWvprQnGi+17yHkxxxkFQr48TdLd5ycGbwpzaeClBdV9HIwub5158wk2MwREfCo7uzLpkRjLXraRbhV5+9ZdCWJOF0MwSXLr9agA5FFpuMtQqsuQpOW/iTHhvLZdxKY/vWcaU4I2TFGUkL2Rd/cdPWRY5m+a/S/2E4OpC3rm8MNXzhvPcO7OigV8youWhT2NKMQe4gQkRCRmpYCJDNNMq5LM8VBFZr1P2R0RXmTZhgiH8c7jCvP0A== X-YMail-OSG: fRsDRoYVM1nHeNS799_S3FEwOKUtHXlN55ang2tM5pgbyO4G74nBomWIYJpuZyr Y2EMrgkwb.ITTD28Ter3eKoBpdKBxIm8uiLVyaP19KNimajFRtqG5N3mcsM4pHsDUmFEOYBoyQJo 9sUSPVP4UDXyvEs3eyJnhsa_Pss5uuwa6I0s95xOzAPfIIWX.ZW3I9_uoX01dw0yujelt7NIP74. F.UqEgDFjHJsGFotg4fYJxhHlY74dNqut9kgVcBSkHaCqSCRT9kRA1mFf.7tu0l7uhXpiOOnSYMU fO9LssYr59G37.pBbhxmnCbZ7OBGaWcjYfykk9uuQjFwaldyL0T.Be8eA.1CbXFm2h6QqZe2ZeVN .mnyMrtV2nDuNYGSl2qFsjpmqb8g6wfMuC2h1poeNKfDK3oxdfcvTjwXk6c90hc4abEME92yz7zp iJgnrn8EGhy5Ms1lutDKezAOc6PtLM6jg5anQjII5An.eS.NIYP2IKo78lDbEIm_5XS4Ph4ez76H LXMveu9neV_3HuAkuOAuGfAtZQy6l685eS4v4.Un5lMFzfxaeo2FoYru5rjCbq9lVpX.2wEa6g2v _qnIac75SHEofoX6fWXfNgMkGLYmSXyqRRd091jYAiOpnllC_g0a4QUu6HLTxGt8cjNXItl6B.M5 qkg6AiLqBtUuPJLWdgaEOiyCGcIDGfKUZKUM7_ExyrkqRy3GATnUjFcERJuQOeXyco2WLf0BOYCA wXhXHrv6eDiEJBOJ_x4vK_jbXIUnDBRf4xEpNeZ27dNQWqMlBNsW6P_mzB_.iZmJQjSQAM3inUtq c.KFL1l8dXgkSXszVVGaaxI9kYkrT6yEyNIeuivmR.8YhuVYoFx6a2DhKYyEePHNo5oDOisHSnRt ZCUuNuzbQS83e6FIUbF6RFhFwKTNTP7jS.DXHhx5BvOQOjaDOJERo94pHPTMKCvqffMn_n1emNUd avSYA3mjJnTAscAEP9ZExfuHvs88oOBz1.GWsKQOcLzHAU1rjRCKxRyOT6Er4RzwMvsse7k05O8n pQz7GWciM4FEXrenYetrRoeiMEOPNwfdO5miaezGEiD1YL6d6y3FIl1ZRIAy74BP8G4XQtsD1mFO 68.mPpUlxiaBGRE.zDqWQRKD7Z.5sgSGzXN0eozCJIJh9hrl3IuE0_4t4eRyCINU6QbWd27vLu0P Md06P5RD3jw2aHvji4otuqbsVpJEybtUxZRUU5JR2svakKhgwnruwuZkWy6BnBP4YfoUUTCBjKXk 7LRom7jTkVFfZhq59LK.q_fjbc2xGWRDNPSlJwXmAFt2HjbG1PWA12pOlTCzDtIsEZLCHN8FoNnO 7ewy38Trz85Xki0LMheUwHpSJZM0MiAzjg_8qF96URgQwtooRwJH4Ib.wdSww9bIkdDRb2nI0MmP vKzyZuO6L8kZV7oY96U_sdDUHflyQFC2zpIBU0ILvcNIv6q4ELkFICa0gEfJq8qS9uV07o7wMm9g 5oZgVmWe.Udx5be2cSvrtrQg8W9EWlhByYAfNmi54hrK6eHWY4JS6.ckLawGBOYxcOIs8Ps_3yoJ BZdxHdMdmfuU6l6gaysnvXidg5rzqPCbY8hVCrfCE80I0dbSvw8TLHowWrHi83HkDpCaWhj0_WSi RyxHvSmNfKV0JZhkMsAxkoveVngGLPJAdUm5G1ByELhb2gH_O1G.nj_7dQjV24D43s7QsvGmEZaw IAjxaotVX5NboqYeqxjAJ38PXSOT1Dl1MClvk8c48m2JUGOSEMYVULhyur7m5IAd0yf6O.l9EOSO u0ITRopVTcuhBaXqGojTjUH512OBCCpMbu9asdz9NajWa4flkhIb5G68rCdpyJg349cGbncKSCRS _Xo3_tfPjt0587LOnZZNhz9Gy8OksHYlTfBuDeegygIVmeQuGfsyX1GKyedObJ7hQpQ3NTSVHWrh r.J5jSeKx4LAitsUL2d6We7qrmCi2CdTodw2FoKCPJ8hOrQXZFdFlDm6fnraZ7XY97CXEODDTHZ. mPMg0fDjKGrMG15oot0AtFm59w3Zb1IzMz0LtzugsZoFssrre5qtd7TRHCVIemI1XfgeCyNwl15W tySCLMQTiQY1s5saoM_K7eEiz_U.0q578VoHSI80dFJcew.X_LcMyguPEtS1P21Gw1o5FBNfxvJq YgMYbi1oDsKvo59ryk3DxRvommmjneSGEwJaCvghLOPitUn6suhTR8lhKQMuuCYKFkeKvdtwaks4 rHcA_OQq59dlEoZ3WZeRZgWj2pHhC68.GIzaZyIqpt_Yo_aduvDMIwKHfY6mUPsXePOWbYL_28N8 YDu6nICF.jx65WrE- X-Sonic-MF: X-Sonic-ID: 6623b004-2b3c-41fb-a76c-cf0028c85f78 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Aug 2024 11:10:20 +0000 Received: by hermes--production-gq1-5d95dc458-rvnnh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2bac3f32d0bec3a1e829d44cb53c0a56; Wed, 07 Aug 2024 11:10:18 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: <0C648446-D075-4981-B348-1525DD1ECD8A@yahoo.com> Date: Wed, 7 Aug 2024 04:10:07 -0700 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <677ACAB7-2932-408D-9C51-A9D1E25ADD32@yahoo.com> References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> <0b3b532c-ae94-439c-81aa-9e80a08af43f@freebsd.org> <4b5a6fa1-3b08-4b8b-8577-c548116d2115@freebsd.org> <0853529b-eb45-43c7-9957-8fe23001c94a@freebsd.org> <0C648446-D075-4981-B348-1525DD1ECD8A@yahoo.com> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.96 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.956]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_THREE(0.00)[4]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-toolchain@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from] X-Rspamd-Queue-Id: 4Wf6sV5yTFz4VCW On Aug 6, 2024, at 11:27, Mark Millard wrote: > On Aug 6, 2024, at 01:56, meloun.michal@gmail.com wrote: >=20 > . . . >> Mark, I think that root case of your problems is that you're trying = to link with libraries (shared or local) with debug information = (unstriped). >=20 > Seems likely that more needs to be stripped (or never generated) > than before. I'll probably manage to regenerate the armv7 context > and test that at some point. It is definitely true that I've > historically kept more of such information around than FreeBSD > does on its own for optimized code: with symbols or debug > information. But it seems that such no longer fits in the armv7 > context for what I've historically done. Confirmed. Use of -gline-tables-only instead of -g allowed lang/rust to build and allowed devel/llvm19 to reach the error that you had reported, getting well past the earlier failure point. But clang*'s -gline-tables-only looks to enable a subset of gcc*'s -g1 and the two do not have a common command line notation. This lead to lang/gcc14 failing to build (unlike before) for how I did this experiment: checking for suffix of object files... configure: error: in = `/wrkdirs/usr/ports/lang/gcc14/work/.build/armv7-portbld-freebsd15.0/libgc= c': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details gmake[1]: *** [Makefile:13527: configure-target-libgcc] Error 1 gmake[1]: *** Waiting for unfinished jobs.... >> This causes a huge memory consumption. I don't remember if it just = wastes address space (because mmapping a large library but never = accessing the debugging information) or if it accessing the debugging = information (so the link needs physical memory for it as well). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 11 21:01:01 2024 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 4WhqnC0B13z5SB2V for ; Sun, 11 Aug 2024 21:01:03 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Whqn96whXz4nb4 for ; Sun, 11 Aug 2024 21:01:01 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1723410062; a=rsa-sha256; cv=none; b=ty+IGpvWX481edGi12eLwQv79QJQGb5KnjGPn8P+0M/+G7Bw76oX/5rEhiMt0iSnWIs4jg 9j8SnqbuA+l8j0NwGn7ZOimJUApm9BgSClgaKKVveKbw+IVT0OmfSzqHingX51A6lhgPSa Ym/yn8E3cBvtCrIB3kLd+A9d6vxZ3OnsV+uUGdsM3a5WecOrimIIG6cCKEluZvdDIL46pE ihE//Fm1JI40Dc4JddhQA5+QuyQmDaBugigb9WWty6t7j1LMWDD6FHCclUlq4SxgO93ELR M4oGoRbacjhu+AdKjtwA/kH44ALQo4ewKhmGRXg5ZHzfQYLyzD44Ae86rI/RVA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1723410062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=bVxPBiC3pTzN3a6EFqhxypu9nNX2yT+9seL2UKXhuao=; b=ixJOaLhl15t0pYoaxmtXfNwYITkltf1CO4Bgb5E+8wPBBiODnHCgCaPoFWWOGa0IDT5JIb sS/b6SmMhXslS6owZibbA2CgBn+AtHIJ9mjSvlCSc8Yttofa4dUcdLBv+tYlPccNG3+Q8x pPb/z1D816xf5QZ/x0IzVIlRMWYn6BYpjKCPRpd0SMy2/n+jW/4UHCXUSiPDaV1vtj/p1R 0uICbEFLfaA/oDA8x+GXXr3+8Syon/Z9SDhiByRg51qiSa5PABkDuyACOrnR+/1n1SA9cJ 0pKA74AV4P/Hson2mLAmKDLmNAyaoEpHVFlehp8wkQRJSTii9eh03mNytr12Nw== 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 4Whqn96YSDz107k for ; Sun, 11 Aug 2024 21:01:01 +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 47BL11X0090765 for ; Sun, 11 Aug 2024 21:01:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 47BL11b4090764 for toolchain@FreeBSD.org; Sun, 11 Aug 2024 21:01:01 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202408112101.47BL11b4090764@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, 11 Aug 2024 21:01:01 +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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="17234100616.e5F8cA.81325" Content-Transfer-Encoding: 7bit --17234100616.e5F8cA.81325 Date: Sun, 11 Aug 2024 21:01:01 +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 | 236165 | crash in malloc with ld.lld and -Wl,--export-dyna Open | 261341 | clang-13 runs out of memory on the port math/open Open | 263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd Open | 271624 | emulators/qmc2: clang crashes during build on {12 Open | 192686 | Segfaults using combinations of -pie -pthread -lm 5 problems total for which you should take action. --17234100616.e5F8cA.81325 Date: Sun, 11 Aug 2024 21:01:01 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
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        |    236165 | crash in malloc with ld.lld and -Wl,--export-dyna
Open        |    261341 | clang-13 runs out of memory on the port math/open
Open        |    263870 | cad/horizon-eda: Crashes clang 13 on aarch64, amd
Open        |    271624 | emulators/qmc2: clang crashes during build on {12
Open        |    192686 | Segfaults using combinations of -pie -pthread -lm

5 problems total for which you should take action.
--17234100616.e5F8cA.81325--