Re: llvm10 build failure on Rpi3

Reply: Mark Millard via freebsd-ports : "Re: llvm10 build failure on Rpi3"
In reply to: Mark Millard via freebsd-ports : "Re: llvm10 build failure on Rpi3"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: bob prohaska <fbsd_at_www.zefox.net>
Date: Thu, 24 Jun 2021 04:30:00 UTC
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