Date: Wed, 23 Jun 2021 21:30:00 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> 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: <20210624043000.GA87740@www.zefox.net> In-Reply-To: <8E78EE69-44A2-429E-AB65-941537DE25A0@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote:
> On 2021-Jun-23, at 15:28, bob prohaska <fbsd at www.zefox.net> wrote:
>
> > On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote:
> >> 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:
> >>>>
> >>>> Not that it helps much, but: 2779096485 == 0xA5A5A5A5
> >>>>
> >>>> It appears that such somehow was involved-in/generated by:
> >>>>
> >>>> [ 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/AMDGPUGISel.td --write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d
> >>>>
> >>>> and that lead to the commented out notation in the output, with the "@2779096485" listed in the comment as well.
> >>>>
> >>>
> >>> 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.
> >>
> > The kernel in use is
> > FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n247405-8fa5c577de3: Fri Jun 18 17:03:19 PDT 2021 bob@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64
> > and it can invoke the debugger using [enter]-tilda-control-b.
>
> If it was a normal style build of main-n247405-8fa5c577de3 then
> both the kernel and world would be debug builds. But it is
> possible to explicitly control if MALLOC_PRODUCTION is used
> instead and the like, based on how doing the build was configured.
> (Lots more can be controlled for the builds.)
>
> I still can not tell if it was a debug (normal) main build or
> not. I would guess it was a normal debug build, no extra
> disabling or enabling of such.
I didn't do anything intentionally to turn off debug. To all else I
plead ignorance 8-)
>
[snipped for brevity]
>
> >> 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 ???alloc???, each byte of uninitialized
> >> allocated memory will be initialized to 0xa5. If set to ???free???, all
> >> deallocated memory will be initialized to 0x5a. If set to ???true???,
> >> both allocated and deallocated memory will be initialized, and if
> >> set to ???false???, junk filling be disabled entirely. This is intended
> >> for debugging and will impact performance negatively. This option
> >> is ???false??? by default unless --enable-debug is specified during
> >> configuration, in which case it is ???true??? 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.
> >>
> > Done and running now. In the interim I tried building llvm10 using
> > make in /usr/ports, but it failed with another python conflict.
>
The poudriere session just ended, with a somewhat different error:
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:1900:41: error: expected expression
/*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/,
^
lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:99: error: expected expression
/*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, /*RC*//*AArch64::FPR64RegClassID: @0*/,
^
2 errors generated.
[ 25% 1396/5364]
The last line is included as a fiducial indicator. Two errors instead of
four, nothing about AMDGPU.
> Intersting. I'm unable to see a:
>
> /usr/local/poudriere/poudriere-system/etc/malloc.conf
>
> via what you have published. But I've no clue if such
> an odd symbolic link would be expected to show up.
>
The link seems visible to find and ls:
root@www:/usr/local/poudriere # find . -name malloc.conf
./poudriere-system/etc/malloc.conf
root@www:/usr/local/poudriere # more ./poudriere-system/etc/malloc.conf
./poudriere-system/etc/malloc.conf: No such file or directory
root@www:/usr/local/poudriere # ls -l ./poudriere-system/etc/malloc.conf
lrwxr-xr-x 1 root wheel 10 Jun 23 14:27 ./poudriere-system/etc/malloc.conf -> junk:false
root@www:/usr/local/poudriere #
The link seems invisible to cat and more, reporting "No such file...."
I'm not sure what might be profitably tried next..... Suggestions welcome!
With my thanks!
bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210624043000.GA87740>