Re: llvm10 build failure on Rpi3
- Reply: bob prohaska : "Re: llvm10 build failure on Rpi3"
- In reply to: Mark Millard via freebsd-ports : "Re: llvm10 build failure on Rpi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 26 Jun 2021 02:52:32 UTC
On 2021-Jun-24, at 17:54, Mark Millard <marklmi at yahoo.com> wrote: > 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.) > I have a RPi4B 8 GiByte with total_mem=1024 (MiBytes) in config.txt that is attempting a devel/llvm10 build in a poudriere jail. But the host FreeBSD has: # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n247562-66aec14a5391-dirty: Fri Jun 25 03:25:00 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400024 1400024 and the chroot that poudriere is using has releng/13 (patch -p2 based): # uname -apKU FreeBSD Rock64_RPi_4_3_2v1p2 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n247562-66aec14a5391-dirty: Fri Jun 25 03:25:00 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA53-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA53 arm64 aarch64 1400024 1300139 So it is not like your context in some ways. Another is: my typical USB3 SSD based file system, not spinning rust. It is UFS in this case. The swap/paging partition shows as (for example): # swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/Rock64swp2 3145728 56360 3089368 2% So: no warning about being mis-tuned vs. the 1 GiByte of used RAM. (I do not know about your context for this.) All the ports that devel/llvm10 needs are already in place for poudriere's use for this experiment. Another point is: # more /usr/local/etc/poudriere.d/options/devel_llvm10/options # This file is auto-generated by 'make config'. # Options for llvm10-10.0.1_3 _OPTIONS_READ=llvm10-10.0.1_3 _FILE_COMPLETE_OPTIONS_LIST=BE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_FILE_SET+=BE_AMDGPU OPTIONS_FILE_SET+=CLANG OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=EXTRAS OPTIONS_FILE_SET+=LIT OPTIONS_FILE_SET+=LLD OPTIONS_FILE_SET+=LLDB OPTIONS_FILE_SET+=LLD_LINK OPTIONS_FILE_SET+=OPENMP OPTIONS_FILE_UNSET+=PYCLANG OPTIONS_FILE_UNSET+=BE_FREEBSD OPTIONS_FILE_SET+=BE_NATIVE OPTIONS_FILE_UNSET+=BE_STANDARD (So I normally build less than BE_STANDARD or BE_FREEBSD would build.) We will see if this is enough common context to replicate the general type of build problem. (Your details very from one attempt to the next so an exact match need not be expected, even if if this does also fail.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)