Date: Sat, 29 Jan 2022 18:03:43 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled Message-ID: <6041A6CC-BBD9-48BD-92B5-243959301A3D@yahoo.com> In-Reply-To: <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@yahoo.com> References: <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <FBD31544-6D8F-40DB-BC36-F0B2BBA78A14@yahoo.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jan-29, at 17:10, Mark Millard <marklmi@yahoo.com> wrote: > On 2022-Jan-29, at 16:15, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On 2022-Jan-28, at 22:43, Mark Millard <marklmi@yahoo.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6041A6CC-BBD9-48BD-92B5-243959301A3D>