From nobody Wed Sep 22 01:27:13 2021 X-Original-To: freebsd-ports@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 BEE1017D4DAF for ; Wed, 22 Sep 2021 01:27:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HDgdV31Ykz3F2m for ; Wed, 22 Sep 2021 01:27:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1632274039; bh=FCRZN3EpD8ReBfaWjyR/nwy5x2+QqmAksDdz+PyxA/s=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=kh+FSOwVwY8lPmfmQGCORpIpwWvJ2s3adWjCjHmxkPWhGBQCXqjW+kN+ulswuKeGI4o++6AYHHkOA/lP/dVUJHAqTPuA50TUucxd6ebC9hsQu9B8OLO82bWscoMfruW0/Xp9BOdopNoXzPTFOl3Np4xo/37aJpXKIvWrzQocEiEgqRa41rFkil7pgLDCX6iy2c0xvOA10lFGi31z5QdSPw5pFYFbY53ejg39cOiiSaGASnavyBBfRTLOSgEJw8Xun3Blyw/KecUOyzYrneXxwzeDU6Pi3nfJ+Lx6gZL8icE1y1+tW5aqY2K23JhjbN7xomDl2xZKzH7AS5zOTOT5+A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1632274039; bh=8uycwg6tZfEFAY5K98R3+QRNOmhO5eD7jdOENcq0KRR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ga22ksQpjPxEei7og5kiOtQkbpgLfqRd/XKhNFkJwmbeCs3IPaog8KqK9jxfN2yC/J0E3rOxFOhy+rfBA6JiYez/pOpT0/DL1tjHf304itd6duVsnKbpOJmf4gLv8LmrhOzDPejT9A+7CPXXnCA/k2CW6lxKRF03AOFKdpIMRvyYysfW7HOMFjD8KKhmDg924oemo+rIwE7/wRIP3BbuI7hdzx/kaExIv/riaKF/4X0wNk4SJ3yXH+15Xym4Ie74Daim+j6VLPxNfCQNjuocty8Zhsz6vXqVcRRUWbVzvtuZxBqOqrDMqOj6DO25lDn+ZSUxXVplb5MwzzT8hDfWWw== X-YMail-OSG: Jx.IZX0VM1myS45LEFAJtA6Ydaco1SyEqEfMXqUeI4x5_8OK7UmF.OYkwx5lamS kGZDgjFpVHtptOwU5.5w75n5VHOpaf3sp8pQoUbuhnORPAkLPuoMNahAzbch15yjeiX2kVk_APAD Dxz3WhB6iCtW5aID7yU2w2RRfsLXoc_pv3VsMl_kjD7FQM7MHJ5HW8rL4ttgc4ZssFDhALn2D8lw fiIQ5KIDGao0.qZO6EuE6ca6XNz9KHIUpsUNJ2TIe119J8R1sF34_nvO.19LS2SKPvNmX2nlsSKJ X4huxpcerpOZyo9fTXpevqHv1xVNLs3rN.HkUnmdx0p8QoQ_VzAcednELyWpewaywWQfbVircwBC wuHAERyTK8JxGG__9rqzj6JQfT6noZ9Wm0FkT8RKRKd.lPoaPf9DbwBcbkCkMRRyljzIK0rAEmKG xLfFTjTIDCh5_rr3.8tWBf6GYWv3s_A9269S7.gxQVueF0DjzHj0s7awdQPLuYdJ3uiu515DYGYv QAFslhGQHcZqdXgoJa6CpBf_U_BJcSUpHoe5KyG.Afkh.EoSmko2efKKWp0AWbLh6.X86PmO4MGQ P8rFY4cDXIYHLbaO7jy2fH8Q59C.MSwnQ2rtoHd46mrgtzcNMh2XoeOe1wsuy4W43GT0WQEKajZj tF75x5aagonte8.HlStsC8NrNeA22KS.Qrc6erLJtKOBDIrNzcoYvE6KsnXlMKueLk2PKSPd9prv oSAUajFxoX13sHdsT_lgbbeufgUCp3R8vycam3_LbSo3VtxwU0.BC09TgrKZ3NZdXwp3eg6egn7d BPGdB8WUomdxUIsDych45gS0xeqoSLv524.e.M1mgXgFKAFUxX5XgftOhCLKS2JGMyo_RekV1WjI s4jD_viAMuRn3Iyv3i8xfaS4GqO.TE4dbnFyF8vQYtVR.cvxHP0nJo522IqaZbbFG33.IO02YEx1 One.BuLl9ATQswl2Ztby_KVNHoduxF8NjqIa5rFKG2koi9D.UA0NT7UZ0rgmyub8NhOYeIjXaUZF 8lV4RG36WYb2zJNnYG3m1elsND36fedis38v45.V9GGcP5h_1RBHmjzID0u3WSHzPDcheGnEbwW2 rGpdTTIG72Je.H_HUZ1nYe_0KAQq0tYCnRVCg1mFNIqma4VKSRqmcF10pz6NaeiAJVMlfvwK.z0G h3zAjvcL.0JnxnqEZLvwpz4f5iDj7Q9Ex323FRa1xRiTljEysepj3sDvd3n2o7.e1._8yjAon9Ph L.d9bjQOrlZAdeYdwjPi3IyhmjC8DGQTDe9GQvC91GZJ9PAw5LDezUvml4Sha_c5AzG08hhWmRuu l.fb44TP4I7g30olnUoazt6N3kHj1kvoQUEz7.efdhWWLHeBpfa0D8yDJjGfLDJAea2Ss5dd3ITt m5RnVQOI.AXmYQyMpbA1dfQerQnyYMi9ANsKfmjtD46M6R1VlfTBkgjCS0BOYfi.AhPTYrqAp2aq vm8Xo71JGsmZO50e4291SpR2RlP0mXH_AWSpgB2ktSUcXlk2aYV5YZZr9X6Jjo1.G38y4Ra4CAsD rFzjeD1J7p5PSo0_.m4qUwZFxURK5slJ5VWj0z97ueDFfuoN..FThllEiGp9tvamjJoK6HUHafbb cxDOPYWfYCvA.EBEFzWhHGIvg0Mmb4ErZran0JaD5gcFsLsz2U_FbHgb.hR46CcHrqlg3CWCnOea 7R2iHGRfhkMXoNRFQ9cfMXY0W2hJOL2tG0iU22MD1hlZ0TeLJCOdYBrE1JUIIBN1HdO4PwDbUb1L UMG8ozxADgs8H_pLxz0hRqECaZjkrO_xyRFoUBCBLbLxxVTFJX3Fr8S1r9XkRc5Ilty1aauIDlD1 h1ZP9x2frZ_mGtr0AGuzm6BGA9KayRTsrya7mEsv1T24Q6awl82p04Qumvoh2MDe8lM8AuV5h7nS IVPIZI6Gd2FSh4_7oM9LhUhOP7mBV2ykJ_svRy6TV42U5DISL.wHytbezPTSOvIaktrqJn.orXAQ kBJOaSq62kXA27puaiPhW8zfIF90T0ymD3IZrXkiyC7Tzw_J94XZOv6XMO9VBOybLnmoT3EQQTfj F2s20MAbP_uzj0K9ga04PxsnuNZg824ai3GywYk3NShnVX0hyPaE9_wdEedf2hwrbH2DUX9rHql_ .KZfzavg.28pf.2wIze4AdGYzgZFuFV5EXFUJS8VhNMobyjPPuRjGXczYbTuXW5tzZ_2I.ZC5tZU nyQi9kN6QZ9tGJogG40_yJ6xDeAqD8T9C3teznAVNYQ_wCytDdKVQs0anREjLgsueLK9UoNKIbue ddIMzLeAlh7M- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Sep 2021 01:27:19 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 32f1b3bfcfad3708140e1e4a0c36ae61; Wed, 22 Sep 2021 01:27:16 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores Date: Tue, 21 Sep 2021 18:27:13 -0700 References: <64B80EEA-DECC-4286-AC80-5BE55B7F19D4@yahoo.com> <7EC14B75-654D-45BA-8260-B3D922B81603@gmail.com> <6A5450DA-A50A-4A9F-AC9B-430016F92D50@yahoo.com> <5FC47541-1F8E-4F51-8D98-6AA7AD538D51@yahoo.com> To: =?utf-8?Q?Lucas_Nali_de_Magalh=C3=A3es?= , freebsd-ports@freebsd.org In-Reply-To: <5FC47541-1F8E-4F51-8D98-6AA7AD538D51@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HDgdV31Ykz3F2m X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kh+FSOwV; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-20, at 17:47, Mark Millard wrote: > On 2021-Sep-20, at 15:10, Mark Millard wrote: >=20 >> On 2021-Sep-20, at 13:58, Mark Millard wrote: >>=20 >>>=20 >>> On 2021-Sep-20, at 12:54, Lucas Nali de Magalh=C3=A3es = wrote: >>>=20 >>>> On Sep 19, 2021, at 6:14 AM, Mark Millard via freebsd-toolchain = wrote:(=E2=80=A6) >>>>=20 >>>> (=E2=80=A6) >>>>=20 >>>> The HoneyComb failure looks to me like like hitting the process >>>> size limitations for armv7, something that did not happen on the >>>> MACCHIATObin Double Shot or RPi4B (fewer cores). >>>>=20 >>>> It looks to me like 32-bit architectures (such as armv7) should >>>> possibly have the multi-threaded link disabled by default >>>> for FreeBSD unless ports are adjusted to disable multi-threaded >>>> individually. >>>>=20 >>>> (=E2=80=A6) >>>=20 >>> There are a few a few problems with your analysis: 32 and 64 bit >>> architectures sizes aren't that small and much of all OSes today >>> evolved around extending these sizes. This doesn't means that one >>> can not use all of it but that the analysis requires a little more = "salt". >>> So it looks like you used all of something=E2=80=A6 maybe you need = to adjust >>> some numbers somewhere. >>>=20 >>> Then, processes and threads existed far before the existence of >>> multicore desktop CPUs. Running with more threads/processes than >>> the number of cores you have only means that some swapping *may be* >>> necessary. If you have enough RAM, swap isn't really necessary. So I = think >>> this makes your suggestion ridiculous. >>>=20 >>=20 >>=20 >> Sorry: a stray click lead to an accidental send of a reply with >> no additional content. >>=20 >>=20 >> The above did not indicate any specific errors for me to >> fix, experiments to try, or even any specific alternate hypothesis >> for the inability to allocate in the failing context that I >> described. So I've no clue of a good way to make any progress from >> what is written. I see no reason to withdraw the suggestion based >> on the above. I'm well aware that there are tradeoffs and that >> the suggestion might not be used even if I've gotten everything >> correct about the failure's cause. >>=20 >>=20 >> After the HoneyComb system is done with the bulk -a activity >> targeting aarch64, I'l likely try bulk -w targeting armv7 in hopes >> of getting a .core for the failure. That will be days away and the >> rebuild attempt for emulators/mame will have to rebuild the >> prerequisite ports (the armv7 packages were deleted before starting >> the aarch64 targeting builk -a). So even more time. >=20 > [I discovered that the aarch64 targeting bulk -a would not > sucessfully build something I wanted in the bulk -a activity. > So I stopped that build and will restart at some point after > updating /usr/ports/ to a version that should build that port.] >=20 > Well, my attempt to build llvm12 with debug info, when targeting > armv7, did not go well. The intent was so that a backtrace > of its linker would be useful to me. >=20 > So this type of experiment proved not useful. >=20 >> I'd consider other evidence gathering alternatives that might >> better indicate specifically why the allocation fails in the >> failing context. But the large nubmer of build steps prior to >> the failing link and such probably limit the options. I created a portmamster/Makefile port building context in which the failing link also occurs, without waiting 11 hr+ for other parts of mame to build each time after the first. I established the context with already built prerequeisite packages that poudriere had aleady made. So only emulators/mame was being built. Then I tried adding an LDFLAGS initial definition to control the threading in that environment to be just one thread: portmaster -CGKDg -mLDFLAGS=3D-Wl,--threads=3D1 --packages-build = emulators/mame The result was: . . . gmake[2]: Entering directory = '/usr/ports/emulators/mame/work/mame-mame0226/build/projects/sdl/mame/gmak= e-freebsd-clang' Linking mame... Compiling src/lib/netlist/prg/nltool.cpp... . . . In other words: no more failure for the link that had been failing. (Note: I was able to see the link command and its --threads=3D1 in top.) Simply avoiding having the extra threads allowed the link to complete --because it needed less memory to be allocated. The rest of the build completed as well. Such is important for native builds via poudreire on systems with many "FreeBSD cpus" for armv7, armv6, and such. I'm not claiming emulators/maem would be the only example, it is just an example that I noticed. Note: in my context I've set the default llvm to llvm12 so that is in use. I was interstested in what sort of problems bulk -a would have on actual armv7 capable hardware. Otherwise emulators/mame is not something that I use. Side notes . . . The GCC_LDFLAGS=3D"${LDFLAGS}" in /usr/ports/emulators/mame/Makefile does nothing for the llvm based build that is used as far as I could tell. Listing such a thread control option in GCC_LDFLAGS did not result in the link command having the option (and so it still failed). It is unfortunately that llvm has varied the notation for controlling the linker's threading over time and that the binutils ld does not accept a compatible notation, last I knew anyway. It may be a while before the option text can be fixed across the then active range of llvm* 's. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)