From nobody Sun Jan 30 02:03:43 2022 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 8DF9B1996F4C for ; Sun, 30 Jan 2022 02:03:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (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 4JmZHY4YByz4YBf for ; Sun, 30 Jan 2022 02:03:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643508226; bh=W291r65kTFEd6sknYqHwZ74pKQsjloVGC05hCkF1E/s=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KHLUGJhUL72rXQNyOiofIo99tD0D8I8TP2m+v5ashn0qji99EGBqz5R4E0UYNlwkybqSofaIS0esRx/B6NQ+WM7lfITcLKMQLGjI0g9vEklP3yjaIFGDpWGlHqFvSuZHeeF9XnIsYL68hF1GouzAXKANvnOhQqWX6Xemt6YiCjJAwSdwpQQ92fnYeJimNW4jkidGXkyP9W09KBnTbTDw0UfsKDnlpmbUXGrEejKiZTuLgmZ8YWzuORCHNGw03V5fg0jYNUhqTuOopTeN4TtwSkWWSHV54FRKpBxzNOEBcpQWrkgg2uzZ2EcoEX7m0WxLso7A3N5VpLu8ZU+YCuNPxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643508226; bh=6uHApRA6iinf/64jC0Icqdv4HdybtlLhNPs/pMnpImD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZDvXGWmPLULF7DzQfPamHQz4/n67RJc9iWbQok7a3xJBVC4Nl+uVESYjxFVM2OWjovS7EqA0i0UZ7aC8i34vO/wQfG9jJfEq9K9kA2gc2Pa9xWv2S3mfhnq+g3y6satsu7MtAGsIGsVCZLZBKr+3kpONptF0IlHmAHdLmT7CycHh7auC3DrXXM0kp+CvspA+SqtuzHLMStPB4++HCIxmyy4UTwWx0EsvGmumS3VyrHl06Jr+e2V6wrKg7yvCLVos/qxsiXxjNxDQcKAI/uhk6Y4zazRBbjKaI4HcpPpX84Awl9Jnr2I02tbFiAuAvVr/ouhtfjnyYk5uW+JzHrUbLg== X-YMail-OSG: BNLXH.EVM1n6xjr2CzfXxk4nMJwXmbf1.bp.f2Kye7s0yv.SOvVXEiEOnprLBYB CZi_scVHPQwzUMTTvyuBPC7Ch2FnHO8LTSkcI5vAE7IOJJ78oF3vYQAU6CojgTFKbTOCckBsflHG QaA5__4e58wZ0qcrAaDr9iFFyUJVYNUlViE.LKIjGs_Xm.bYdtjba32wg6rZlrqOzlw_lh4SCfuP cOWRldgC3Sp14WQkaDtDQfd0u_ecAorHi7rUUtJReDWpStW02hPfdkLJTAH17IoR.l4SHquUiHV8 JEgO_ZwCjeHzeUuAlLWVqPWqfB6GUB3Nq2Xttp_1Fnjr63evt5VCt_aFpEbTsyAhp3QquRZWBJxC utUPM.jUrxhvFnvh9swCFdMEjC7mTc86qv5MGNk89k8CS0f_2b_iPx73nrAroJ3arKsSRIhqviQi wiEM2WZwfbRv.HbDENvsviVZNOMaanmG23BpOZ.S_bikIjJMLzjaxyBIHRMcOdHa0Ffedp7XdwIT pXneMSNiHxjY4v4GREXZi086HGFbGCLd7MAP0tXUmy8V1aOvs15KIgrkGuUobTzFuLIqV_du04I2 5pEvQ8Yc0sI4nGBsLLcsI8joaZpGdUBWZvD_DczKCmU.TN5ENhtB1d_KI2HOnSqUnaD7sr2vP2kC VesmeEPCXiXcFzJ9LePJCjCmKUdGqPZa7f6vY1CyZOBDNsznj193Ag8_bX55OtZl3MYQEqSPeObR W6kVSNLqtGh9quss4uw1un3pSnFdIXi4WsQombwbqmKPKIunVgbeELaZTB3dtpmDylCnn2EJxkx3 zc746mXFA7i2Js4e02MPEGuYg3lqwVj8f1yqgNX0QScvxF3B59mGcDtojmLxWjh.wer0L7MsTVrt x46mjMxOCaZ_e.zGE6KUrTZNW9nayoIVb.1fpTa8jjNAOeaFTykXjT9ebIfnXzuDU56L2ghU2VPF 8uYvNouAPWNZG9F7ATdS.ktHBY4i5WFW8ax0MleDbeBpXBVPzoKkWl4iOZMFa9LUct9.VIiAQCOW 0MDCqDaTegHqcW_WZowrRgK0_yWK8th.OQLoXUDxTaGDGs.obYzOLYIHf1f3WtjJEuiU_Kq42dYt qGXzSPYZXbEiDqt7nwbSNnwtB0ECjH_1gIg7tpdx9n0goyD4GHal9uAUGwdCw6r8fEt8hpyPpO9X cCv2ap0rLRNzC0VVqbXiqPp7K241mqgzFZgteefAqeBZ.mbtfgDuIA4OLggn0rSGmVpg2IxkXK8X BT26BSqIBSebaJA8XzTCWhJtz1wXah8sgYGriLBh7aqmMI56l84dURpT.m_WGBFHjwj2qOWeXD8r 2CPwEv4RkGARCjjOMyUY.b7HLW0yxydPc8YxF5bYsrr98bOzmXw1N9NKa4_Wz.oREVLXnbkJNAIr y7a.RLONFMDqq7bQt4xmULe6eRZv5LqNNEjT8vIllySdKO4wcn1gdooOBnf70ebArm_Kl5aBniW1 Q7Rm_aU57O.al9g_zAhhWC9i_KOo2ZpmJuv8fCPi_4cRINFg3vIL9_OCcFjU9fNo9ndrgmyaLdmT 3YTS2Ii0AzY3YamCWJcZ5jvajL7I9Jl7dwfrvfC4dezeTpMVodFc1c4w.SIHkGGhwy6a7NHk6mOA YAdHNqwRbFKp1dpldN.6APLKnpA3T2FdTOb.PxGXdUzCoRZnaOz._osq57KjnJgW6E7v9litUIVR Y.00eMOVyNsGtwPhTvai4kvX_UG4Y5_LHPeF9FJgTynFDyddMtRWOwdGbNFH6GLrJUMS7gaivtXR bhM2lHPYdQRqmt0K2w4BN6CByJhZ.K9yqw28yhAB6Clm_nS63NTB0Qwph.gG4S2flt9o.ynfGPMa TaEiluJPnGfEIfYQYy99CRkZTKzpeWmrfVVrrFaJbD8QJvwmJ70YGcVdwqmabVd1dXP3axc0Q2zY xEWj5or3SdCLabPrG_uCOgmfCFw7NU_mOkICvaZlrkZSkAee9170cofoJ9MRgMXefrYY9Cz9CUyq 9Ii9UQ14AzX10EBSTUyP.DrAunezy1lLiOtBitnfYSli0AGtgyeLhbv5tQ5ZhWAlYLsG7qYy2L99 _OxBcsTlb_vkSHNJluXGXI3hVG_TtmqYMq2r5kqv6LGafDP3rCCkD_zsvfZ3Lxj5znxPsED6mKOQ sh8kEUa7FPKUaciDQj8wB8BJPnmu.JnlADfzGnFOLvbyIQ6S3u8w4W6SKW_OFnAlpTX.NZ_oXKxy 03heV6ruxS8LEYD_3ZdY4kp0xCWoHeh1X7CxdFSUY9cEXHgL.CKpnre0S2iBz4ZUAOGLm5j2VFmw zO_DaJXieXaahPJ._MWjyyS2gdtjmcIyWKlrybgdfNNyfEuAuqg95nOYpwsWN3UJuRH0xh00znWM ShM8Bqw36hSUzXYyytpoo4jy9f4.WGZ.oP6pSDn1WnX7VpqlHcV74.ISfSez4uUDeS0SQDA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 02:03:46 +0000 Received: by kubenode533.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3a9cf4c12eab749c7393f32cccff8586; Sun, 30 Jan 2022 02: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 14.0 \(3654.120.0.1.13\)) Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled From: Mark Millard In-Reply-To: <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> Date: Sat, 29 Jan 2022 18:03:43 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <6041A6CC-BBD9-48BD-92B5-243959301A3D@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmZHY4YByz4YBf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KHLUGJhU; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; 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]; 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.32:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 5611 Lines: 158 On 2022-Jan-29, at 17:10, Mark Millard wrote: > On 2022-Jan-29, at 16:15, Mark Millard wrote: >=20 >> On 2022-Jan-28, at 22:43, Mark Millard wrote: >>=20 >>> An FYI: I do not have problems building gmock_main-f5c28a.cpp --even >>> with no swap at all on an RPi3B: >>>=20 >>> # swapinfo >>> Device 1K-blocks Used Avail Capacity >>> /dev/gpt/RPi3Bswp2g 2097152 0 2097152 0% >>> # swapoff /dev/gpt/RPi3Bswp2g >>> # swapinfo >>> Device 1K-blocks Used Avail Capacity >>> # ./gmock_main-f5c28a.sh >>> # ls -Tldt gmock_main-f5c28a* >>> -rw-r--r-- 1 root wheel 134840 Jan 28 22:02:09 2022 = gmock_main-f5c28a.o >>> -rwxr-xr-x 1 root wheel 4509 Jan 21 23:26:29 2022 = gmock_main-f5c28a.sh >>> -rw-r--r-- 1 root wheel 7044253 Jan 21 23:26:29 2022 = gmock_main-f5c28a.cpp >>>=20 >>> You could try such on other aarch64 RPi*'s and see if >>> any of them require swap space to do the compile. (The >>> same for any other example .cpp and .sh pairs.) My >>> expectation is that you will find that they do not >>> require any swap space be enabled. >>>=20 >>> This is main [so: 14] instead of stable/13 . My only >>> stable/13 environments at this point are bectl (so >>> under ZFS). I do not not try to use ZFS with less than >>> 8 GiBytes of RAM: default configuration instead of >>> tailoring for smaller amounts of RAM. >>>=20 >>> But I've also built under stable/13 (with ZFS involved). >>> top did not show the build of the .o using significant >>> memory under stable/13. >>>=20 >>> Part of the point of the .cpp that the compiler generated is that >>> it uses no include files: everything is expanded inline for >>> the source code. Thus, no other c++ source file should be involved. >>> I got the copy from where you posted it. That it builds in my >>> context indicates that it is unlikely for your or my copy of the >>> source code to be corrupted. >>>=20 >>> That leaves basically compiler binaries (and supporting files) as >>> potential sources of variation, possibly via corruption. (This >>> was only the production of a .o file. Fewer toolchain programs >>> are involved.) >>>=20 >>>=20 >>> For reference . . . >>>=20 >>> Under main [so: 14] (UFS context example): >>>=20 >>> # c++ -v >>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >>> Target: aarch64-unknown-freebsd14.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>>=20 >>> Under stable/13 (ZFS and bectl context example): >>>=20 >>> # c++ -v >>> FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) >>> Target: aarch64-unknown-freebsd13.0 >>> Thread model: posix >>> InstalledDir: /usr/bin >>>=20 >>> So, for as much as the compiler identifies its own content, they >>> are supposedly the same, other than having a different default >>> Target FreeBSD variant. (But I do not expect that the compiler >>> identifies something unique to the combination of FreeBSD specific >>> patches or other FreeBSD choices that are involved.) >>=20 >> A potential source of variability in the llvm part >> of buildworld results is if LLVM assertions are >> enabled vs. disabled. My buildworlds are based, in >> part, on: >>=20 >> MALLOC_PRODUCTION=3D >> WITH_MALLOC_PRODUCTION=3D >> WITHOUT_ASSERT_DEBUG=3D >> WITHOUT_LLVM_ASSERTIONS=3D >>=20 >> But you report a mix of results on your systems. Might >> you have a mix of (implicit?) WITH_LLVM_ASSERTIONS=3D vs. >> WITHOUT_LLVM_ASSERTIONS=3D FreeBSD builds across your >> systems where you tried the .sh on the .cpp file? >>=20 >> Similar points could be questioned in other buildworld >> results for (implicit?) WITH_ASSERT_DEBUG=3D vs. >> WITHOUT_ASSERT_DEBUG=3D use for the builds. But this >> seems unlikely to lead to llvm-specific behavioral >> differences. >=20 >=20 > I set up and tried a context that was using > WITH_LLVM_ASSERTIONS=3D and the .sh based build > of the .cpp I have still worked (no swap space > active). >=20 I tried the .sh after having zfs.ko loaded. It still compiled the .cpp fine. (main [so: 14] context.) Unfortunately: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/?C=3DM&O=3DD= does not have any RPi3* supporting images to try. (RPi*'s are not the only aarch64 things missing.) Anything else requires dealing with Paritioning, RPi* firmware, U-Boot, and the FreeBSD loader separately from getting FreeBSD itself in place on media (after partitioning). = https://artifact.ci.freebsd.org/snapshot/stable-13/037fe75b38c1f177087076a= 1027f6b035db8859f/arm64/aarch64/?C=3DM&O=3DD has files that can be used put down a debug-build copy of FreeBSD. (There likely is a better match to your boot media's version available too. I just picked a recent example.) If the likes of: http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/?C=3DM&O=3DD= had an appropriate image, one test would be to put the image on a microsd card and also get the .sh / .cpp pair in place were it would be accessible, and boot and try the test just with the micrsd card in use, no other media. (Remember that no swap need be active.) If it worked, then the RPi3*'s normally in use media would have been likely the source of the problem. (Points a direction for further investigation.) But if it failed, that would have shown a general problem for stable/13 . (Picking an image as near to your existing boot's version as was reasonable would have likely been a good thing for this kind of testing.) =3D=3D=3D Mark Millard marklmi at yahoo.com