From nobody Thu Jun 24 04:30:00 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7ED4811D52F0; Thu, 24 Jun 2021 04:30:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9Rxh1LYtz53gZ; Thu, 24 Jun 2021 04:29:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15O4U1t7088681 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Jun 2021 21:30:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15O4U0Ah088680; Wed, 23 Jun 2021 21:30:00 -0700 (PDT) (envelope-from fbsd) Date: Wed, 23 Jun 2021 21:30:00 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210624043000.GA87740@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> X-Rspamd-Queue-Id: 4G9Rxh1LYtz53gZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote: > On 2021-Jun-23, at 15:28, bob prohaska wrote: > > > On Wed, Jun 23, 2021 at 02:03:42PM -0700, Mark Millard wrote: > >> On 2021-Jun-23, at 10:43, bob prohaska 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