Re: llvm10 build failure on Rpi3

From: Mark Millard via freebsd-ports <>
Date: Fri, 25 Jun 2021 00:54:36 UTC

On 2021-Jun-24, at 17:16, bob prohaska <fbsd at> wrote:

> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote:
> [huge snip]
>> So: Even going back to June 9 may messed up nfs
>> use. (I've no clue what services you depend on
>> or in what contexts.) You might need to disable
>> nfs even trying to start at the next boot before
>> booting into such an older kernel.
> No NFS involved. Right now the machine is running
> FreeBSD 13.0-CURRENT #5 main-c255664-g4d64c7243d26: Sat Jan  9 11:27:58 PST 2021
> arm64

I'll note that the output of -apKU fpr uname:

# uname -apKU
FreeBSD CA72_16Gp_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #3 stable/13-n246090-6e2623c012c3-dirty: Thu Jun 24 13:59:44 PDT 2021     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1300509 1300509

has some extra text at the end that would indicate
when the world is mismatched with the kernel: the
last 2 numbers end up not equal and the prefix 13
vs. 14 would indicate crossing a major version.
(Kernel newer, world older can be valid/supported.)

> and repeating the previous attempt to build devel/llvm10 with no other
> intentional changes. 
>> Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got
>> #define __FreeBSD_version 1400000 back on Jan-22.
>> Running newer worlds on older kernels is not supported.
>> Generally folks to not track the KBI changes vs. the
>> consequences of not having the right KBI. This makes
>> interpreting results difficult even when it appears to
>> work. There can be mixes like NFS not working but other
>> things working. There could be corruptions but such
>> may not be likely. Do you have what you consider
>> sufficient backups it case things get messed up? (That
>> might be the status of being okay with starting over
>> if something really bad happens.)
> No backups, but I'm not averse to starting from scratch on
> this particular machine.
> As it happens, the poudriere session ended much as before:
> FAILED: lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o 
> /usr/bin/c++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Target/AArch64 -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64 -Iinclude -I/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include -fvisibility=hidden  -fno-exceptions -std=c++14 -MD -MT lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o -MF lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o.d -o lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSelector.cpp.o -c /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector.cpp
> In file included from /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AArch64InstructionSelector.cpp:312:
> lib/Target/AArch64/ error: expected expression
>        /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                        ^
> lib/Target/AArch64/ error: expected expression
>        /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                                                                                  ^
> lib/Target/AArch64/ error: expected expression
>      /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                      ^
> lib/Target/AArch64/ error: expected expression
>      /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                                                                                ^
> 4 errors generated.
> [ 25% 1396/5364]

This still had junk:false in /etc/malloc.conf ?

So, if it is a kernel problem, it is an old one and
likely also in releng/13 and stable/13.

Beyond other things that I've listed, there is also
that you have an unusual context in that you use

So I'm going to suggest using an official kernel build
as built by the systems, one that is not

there is:


and, if you want the debug information to match:


These are compressed tar archives. Possibly after
first uncompressing, a command of the form:

# tar -xpf NAME -C /

will overwrite what you now have installed. (Make any
desired copies first.) Then you can reboot and use
the kernel. The debug info ends up places like:

# ls -Tld /usr/lib/debug/boot/*/
drwxr-xr-x  2 root  wheel  647 May 27 12:39:52 2021 /usr/lib/debug/boot/kernel.old/
drwxr-xr-x  2 root  wheel  647 Jun 24 14:14:08 2021 /usr/lib/debug/boot/kernel/
drwxr-xr-x  2 root  wheel    2 Apr  8 22:40:04 2021 /usr/lib/debug/boot/modules/

So appropriate copies from there may be involved.

(I do this sort of . .
thing to approximately bisect without spending time on doing
builds and if a problem reproduces that means my personal
builds are not at fault.)

> Not sure what to try next.

I gather that no RPi4B is available to move the media
to? (Having more RAM but being able to force much of
it to be ignored can be handy as a test environment
for this kind of context.)

Mark Millard
marklmi at
( went
away in early 2018-Mar)