Re: llvm10 build failure on Rpi3

On 2021-Jun-24, at 17:16, bob prohaska <fbsd at www.zefox.net> 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
>    [email protected]:/usr/obj/usr/freebsd-src/arm64.aarch64/sys/GENERIC-MMCCAM 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/AArch64GenGlobalISel.inc:33194:41: error: expected expression
>        /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                        ^
> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected expression
>        /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                                                                                  ^
> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected expression
>      /*GIM_CheckRegBankForClass: @0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/,
>                                      ^
> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: 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
GENERIC-MMCCAM.

So I'm going to suggest using an official kernel build
as built by the ci.freebsd.org systems, one that is not
GENERIC-MMCCAM. In:

https://artifact.ci.freebsd.org/snapshot/main/66aec14a5391bda1e9a20f5e4381626797c3e0fb/arm64/aarch64/

there is:

kernel.txz

and, if you want the debug information to match:

kernel-dbg.txz

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 https://artifact.ci.freebsd.org/snapshot/. . .
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 yahoo.com
( dsl-only.net went
away in early 2018-Mar)