Date: Wed, 23 Jun 2021 14:03:42 -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: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> In-Reply-To: <20210623174338.GA84853@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <DD8D8FE1-F02E-4A25-8F2B-5672F10E7268@yahoo.com> <20210623174338.GA84853@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jun-23, at 10:43, bob prohaska <fbsd at www.zefox.net> wrote:
> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote:
>>=20
>> Not that it helps much, but: 2779096485 =3D=3D 0xA5A5A5A5
>>=20
>> It appears that such somehow was involved-in/generated by:
>>=20
>> [ 24% 1326/5364] cd /wrkdirs/usr/ports/devel/llvm10/work/.build && =
/wrkdirs/usr/ports/devel/llvm10/work/.build/bin/llvm-tblgen =
-gen-global-isel -I =
/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU =
-I /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/include -I =
/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target =
/wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AMDGPU/AMD=
GPUGISel.td --write-if-changed -o =
lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d =
lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d
>>=20
>> and that lead to the commented out notation in the output, with the =
"@2779096485" listed in the comment as well.
>>=20
>=20
> A Pi4 doing a bulk build of chromium, lxqt and apache has gone far =
past that
> point building llvm10, suggesting the fault lies somewhere in my =
setup.
I'm not so sure of that for the 0xA5A5A5A5u value. You run
main [so: 14 at this point]. Is it a debug build? Or a
non-debug build? I expect that 0xA5A5A5A5u has some specific
debug-build potential meaning.
For example, 0xA5u byte values might be the value that newly
allocated memory is initialized to. Looking . . . man jemalloc
(the memory allocator implementation used by FreeBSD) reports:
opt.junk (const char *) r- [--enable-fill]
Junk filling. If set to =E2=80=9Calloc=E2=80=9D, each byte of =
uninitialized
allocated memory will be initialized to 0xa5. If set to =
=E2=80=9Cfree=E2=80=9D, all
deallocated memory will be initialized to 0x5a. If set to =
=E2=80=9Ctrue=E2=80=9D,
both allocated and deallocated memory will be initialized, =
and if
set to =E2=80=9Cfalse=E2=80=9D, junk filling be disabled =
entirely. This is intended
for debugging and will impact performance negatively. This =
option
is =E2=80=9Cfalse=E2=80=9D by default unless --enable-debug =
is specified during
configuration, in which case it is =E2=80=9Ctrue=E2=80=9D by =
default.
So, if you have junk filling enabled, I expect that you ran
into a legitimate defect in the llvm-tblgen in use. Having
Junk Filling disabled might be a workaround.
There is /etc/malloc.conf as a way of controlling the behavior:
ln -s 'junk:false' /usr/local/poudriere/poudriere-system/etc/malloc.conf
I suggest you retry building after getting the above in place.
If it does not get the 0xA5A5A5A5u value, that would be
more evidence of a uninitialized-memory defect in the llvm-tblgen
involved.
I do not normally run debug builds and so would not have
run into 0xA5A5A5A5u from Junk Filling of memory allocations.
I'm not sure when I can setup and do a junk filling experiment
(in a debug main build?). But it looks like some independent
compare/contrast activity might be appropriate.
> The instructions you gave for setting up poudriere seemed to work =
perfectly
> initially, but since that time both world and kernel have been updated
> along with ports. Is it necessary or advisable to alter =
/usr/local/poudriere,
> either by update commands or complete replacement?=20
I will note that your log file reports:
Host OSVERSION: 1400023
Jail OSVERSION: 1400019
So your jail's OSVERSION is older than the environment
that it is running in. (Unlikely to contribute to the
0xA5A5A5A5u as far as I can tell.) In other words, you
have not updated your:
/usr/local/poudriere/poudriere-system/
to 1400023 as far as I can tell.
Separately from that, for poudriere itself:
I do not know if you are using ports-mgmt/poudriere-devel vs.
ports-mgmt/poudriere . But, whichever, it is a port and is
one of the ports that should be built when it has updated
when you update /usr/ports content and should then have its
install be updated via pkg like the other ports.
I list ports-mgmt/poudriere-devel in the file with the other
ports that I list in ~/origins/CA72-origins.txt and I use
that file via -f in the bulk command.
But nothing about these is likely to avoid the 0xA5A5A5A5u
issue that you ran into.
=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?6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF>