Date: Thu, 24 Jun 2021 17:54:36 -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: <D0845F74-A9A9-4588-910B-B55F9216C9C9@yahoo.com> In-Reply-To: <20210625001651.GA98214@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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]
>>=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
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.=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]
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/66aec14a5391bda1e9a20f5e4381=
626797c3e0fb/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.)
=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?D0845F74-A9A9-4588-910B-B55F9216C9C9>