Re: llvm10 build failure on Rpi3

From: Mark Millard via freebsd-ports <freebsd-ports_at_freebsd.org>
Date: Fri, 25 Jun 2021 19:52:32 -0700
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_at_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_at_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: _at_0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64::FPR64RegClassID: _at_0*/,
>>                                       ^
>> lib/Target/AArch64/AArch64GenGlobalISel.inc:33194:99: error: expected expression
>>       /*GIM_CheckRegBankForClass: _at_0*/, /*MI*/0, /*Op*/0, /*RC*//*AArch64::FPR64RegClassID: _at_0*/,
>>                                                                                                 ^
>> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:39: error: expected expression
>>     /*GIM_CheckRegBankForClass: _at_0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: _at_0*/,
>>                                     ^
>> lib/Target/AArch64/AArch64GenGlobalISel.inc:40087:97: error: expected expression
>>     /*GIM_CheckRegBankForClass: _at_0*/, /*MI*/0, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: _at_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_at_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_at_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)
Received on Sat Jun 26 2021 - 02:52:32 UTC

Original text of this message