Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled

In reply to: Mark Millard : "Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 30 Jan 2022 02:03:43 UTC
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:
> 
>> On 2022-Jan-28, at 22:43, Mark Millard <marklmi@yahoo.com> wrote:
>> 
>>> An FYI: I do not have problems building gmock_main-f5c28a.cpp --even
>>> with no swap at all on an RPi3B:
>>> 
>>> # 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
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> 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.)
>>> 
>>> 
>>> For reference . . .
>>> 
>>> Under main [so: 14] (UFS context example):
>>> 
>>> # 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
>>> 
>>> Under stable/13 (ZFS and bectl context example):
>>> 
>>> # 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
>>> 
>>> 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.)
>> 
>> 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:
>> 
>> MALLOC_PRODUCTION=
>> WITH_MALLOC_PRODUCTION=
>> WITHOUT_ASSERT_DEBUG=
>> WITHOUT_LLVM_ASSERTIONS=
>> 
>> But you report a mix of results on your systems. Might
>> you have a mix of (implicit?) WITH_LLVM_ASSERTIONS= vs.
>> WITHOUT_LLVM_ASSERTIONS= FreeBSD builds across your
>> systems where you tried the .sh on the .cpp file?
>> 
>> Similar points could be questioned in other buildworld
>> results for (implicit?) WITH_ASSERT_DEBUG= vs.
>> WITHOUT_ASSERT_DEBUG= use for the builds. But this
>> seems unlikely to lead to llvm-specific behavioral
>> differences.
> 
> 
> I set up and tried a context that was using
> WITH_LLVM_ASSERTIONS= and the .sh based build
> of the .cpp I have still worked (no swap space
> active).
> 

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=M&O=D

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/037fe75b38c1f177087076a1027f6b035db8859f/arm64/aarch64/?C=M&O=D

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=M&O=D

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.)

===
Mark Millard
marklmi at yahoo.com