Migrating from -current to stable/12 on RPI2B (ARMv7)

[Mark Millard]

On 2020-Dec-27, at 20:48, bob prohaska <fbsd at www.zefox.net> wrote:

> Having a bit of trouble migrating to stable/12 from 13.0-CURRENT 
> FreeBSD 13.0-CURRENT #3 r368820: Sat Dec 26 19:01:50 PST 2020     
> bob at www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC-MMCCAM  arm
> 
> This is on a Pi2B v1.1 The MMCCAM kernel option was added for sake 
> of the experiment and hasn't, up to now, been accompanied by any
> visible problems. World and kernel have been built many times, no
> problems. 
> 
> Buildworld keeps stopping at
> --- clang.full ---
> c++ -O -pipe -fno-common -mlong-calls -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm -I/usr/freebsd-src/contrib/llvm-project/clang/include -I/usr/freebsd-src/lib/clang/include -I/usr/freebsd-src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv7-unknown-freebsd12.2-gnueabihf\" -DLLVM_HOST_TRIPLE=\"armv7-unknown-freebsd12.2\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/freebsd-src/arm.armv7/tmp\" -DLLVM_TARGET_ENABLE_ARM -DLLVM_NATIVE_ASMPARSER=LLVMInitializeARMAsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeARMAsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeARMDisassembler -DLLVM_NATIVE_TARGET=LLVMInitializeARMTarget -DLLVM_NATIVE_TARGETINFO=LLVMInitializeARMTargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeARMTargetMC -ffunction-sections -fdata-sections -gline-tables-only -Wno-for
> mat-zero-length -Qunused-arguments -I/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/include -fno-exceptions -fno-rtti -std=c++14 -stdlib=libc++ -Wno-c++11-extensions  -Wl,--gc-sections -static  -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/legacy/usr/lib -o clang.full  cc1_main.o cc1as_main.o cc1gen_reproducer_main.o driver.o /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libclang/libclang.a /usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/clang/libllvm/libllvm.a -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libz -lz -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libexecinfo -lexecinfo -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libelf -lelf -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/ncurses/ncursesw -lncursesw -L/usr/obj/usr/freebsd-src/arm.armv7/tmp/obj-tools/lib/libthr -lpthread -legacy
> ld: error: failed to open clang.full: Cannot allocate memory
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [clang.full] Error code 1
> 
> make[4]: stopped in /usr/freebsd-src/usr.bin/clang/clang
> 1 error
> 
> The failure occurs many minutes after the log entry appears. 
> No errors on the console, swap tops near half a gig. The 
> stable/12 sources being compiled were obtained via git. The 
> -current sources used to compile the running system were 
> obtained using svnlite. 
> 
> I don't recall seeing this much swap used before by armv7, 
> but that's the only notable oddity.  
> 
> The stable/12 sources have been updated every day for the 
> past few in hopes the trouble might go away, the -current 
> sources seem to be updated as far as svnlite goes. 
> 
> Any suggestions appreciated, thanks for reading
> 

I presume the historical system tuning for small memory systems
from our past investigations and help that we got.

You do not mention -j4 vs. -j1 or the like. I'm assuming -j1 has
been tried.

You have not said if you have adjusted the likes of:
kern.maxswapzone or VM_SWZONE_SIZE_MAX or if you get the boot
notices about the likes of:

warning: total configured swap (??? pages) exceeds maximum recommended amount (??? pages).

Mistuning these could lead to RAM fragmentation issues as I
understand.

Since the allocation failure is reported by ld while it tries to
produce clang.full , I wonder if you have used:

LDFLAGS.lld+= -Wl,--no-threads

in, say, /etc/make.conf ? If not, the llvm ld will try to use
all 4 RPi2 v1.1 cores (via threads, not via processes) and, from
what I've seen, will end up trying to use more RAM than when it
runs single-threaded (main thread only). Of course, links then
take longer to complete. (LLVM ld actually ends up up with 4+2
threads, counting the processes's main thread as well.)

Except on the machines with plenty of RAM (by a large margin for
the hardware-thread count), I use --no-threads for contexts where
I can readily control such.

(Ports do not use LDFLAGS.lld and gnu's linker does not tolerate
--no-threads as a command line option. So "readily" is limited to
buildkernel and buildworld .)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)