Re: llvm10 build failure on Rpi3
- Reply: Mark Millard via freebsd-ports : "Re: llvm10 build failure on Rpi3"
- In reply to: bob prohaska : "Re: llvm10 build failure on Rpi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 25 Jun 2021 00:54:36 UTC
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 > bob@www.zefox.org:/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)