From nobody Mon Aug 05 08:03:33 2024 X-Original-To: freebsd-arm@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 4WcpqF1p6Cz5Smyy 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 4WcpqC4LdCz4nqM 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: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@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:+]; 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.147: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-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4WcpqC4LdCz4nqM 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