Date: Fri, 25 Jun 2021 19:52:32 -0700 From: Mark Millard via freebsd-ports <freebsd-ports@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ports <freebsd-ports@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: Re: llvm10 build failure on Rpi3 Message-ID: <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> In-Reply-To: <D0845F74-A9A9-4588-910B-B55F9216C9C9@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <DD8D8FE1-F02E-4A25-8F2B-5672F10E7268@yahoo.com> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <D0845F74-A9A9-4588-910B-B55F9216C9C9@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=20
>> On Thu, Jun 24, 2021 at 10:41:38AM -0700, Mark Millard wrote:
>> [huge snip]
>>>=20
>>> 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.
>>=20
>> 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-MMCCA=
M arm64
>=20
> I'll note that the output of -apKU fpr uname:
>=20
> # 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
>=20
> 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.)
>=20
>> and repeating the previous attempt to build devel/llvm10 with no =
other
>> intentional changes.=20
>>=20
>>> Jan 9 predates 14 and 13.0-RELEASE: sys/sys/param.h got
>>> #define __FreeBSD_version 1400000 back on Jan-22.
>>>=20
>>> 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.)
>>>=20
>> No backups, but I'm not averse to starting from scratch on
>> this particular machine.
>>=20
>> As it happens, the poudriere session ended much as before:
>>=20
>> FAILED: =
lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel=
ector.cpp.o=20
>> /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=3Ddate-time =
-Werror=3Dunguarded-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=3Dhidden -fno-exceptions -std=3Dc++14 =
-MD -MT =
lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel=
ector.cpp.o -MF =
lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel=
ector.cpp.o.d -o =
lib/Target/AArch64/CMakeFiles/LLVMAArch64CodeGen.dir/AArch64InstructionSel=
ector.cpp.o -c =
/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA=
rch64InstructionSelector.cpp
>> In file included from =
/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA=
rch64InstructionSelector.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]
>=20
> This still had junk:false in /etc/malloc.conf ?
>=20
> So, if it is a kernel problem, it is an old one and
> likely also in releng/13 and stable/13.
>=20
> Beyond other things that I've listed, there is also
> that you have an unusual context in that you use
> GENERIC-MMCCAM.
>=20
> 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:
>=20
> =
https://artifact.ci.freebsd.org/snapshot/main/66aec14a5391bda1e9a20f5e4381=
626797c3e0fb/arm64/aarch64/
>=20
> there is:
>=20
> kernel.txz
>=20
> and, if you want the debug information to match:
>=20
> kernel-dbg.txz
>=20
> These are compressed tar archives. Possibly after
> first uncompressing, a command of the form:
>=20
> # tar -xpf NAME -C /
>=20
> 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:
>=20
> # 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/
>=20
> So appropriate copies from there may be involved.
>=20
> (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.)
>=20
>> Not sure what to try next.
>=20
> 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.)
>=20
I have a RPi4B 8 GiByte with total_mem=3D1024 (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/arm6=
4.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/arm6=
4.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=20
# This file is auto-generated by 'make config'.
# Options for llvm10-10.0.1_3
_OPTIONS_READ=3Dllvm10-10.0.1_3
_FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS LIT LLD LLDB =
LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD
OPTIONS_FILE_SET+=3DBE_AMDGPU
OPTIONS_FILE_SET+=3DCLANG
OPTIONS_FILE_SET+=3DDOCS
OPTIONS_FILE_SET+=3DEXTRAS
OPTIONS_FILE_SET+=3DLIT
OPTIONS_FILE_SET+=3DLLD
OPTIONS_FILE_SET+=3DLLDB
OPTIONS_FILE_SET+=3DLLD_LINK
OPTIONS_FILE_SET+=3DOPENMP
OPTIONS_FILE_UNSET+=3DPYCLANG
OPTIONS_FILE_UNSET+=3DBE_FREEBSD
OPTIONS_FILE_SET+=3DBE_NATIVE
OPTIONS_FILE_UNSET+=3DBE_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.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A26965D-2DFD-4A46-A171-A382A61E3CFB>