From nobody Wed Jun 23 22:28:38 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 46BDF11DDB92; Wed, 23 Jun 2021 22:28:38 +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 4G9Hwj6ft1z4Xb1; Wed, 23 Jun 2021 22:28:37 +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 15NMScoQ085710 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 23 Jun 2021 15:28:39 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15NMScgO085709; Wed, 23 Jun 2021 15:28:38 -0700 (PDT) (envelope-from fbsd) Date: Wed, 23 Jun 2021 15:28:38 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210623222838.GA85566@www.zefox.net> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@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: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> X-Rspamd-Queue-Id: 4G9Hwj6ft1z4Xb1 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 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. > 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. > 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? > > 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. > After one of the world/kernel rebuilds I attempted to repeat your poudriere setup instructions, thinking it would update the setup. IIRC both commands were refused, not with an error, but more like a "don't do that" sort of message. I fumbled for a while with poudriere ports -u, but couldn't get the syntax right. Then I noticed a reference to null-mounting /usr/ports, which strongly suggested any updates to ports would be picked up by default. > Separately from that, for poudriere itself: > > I do not know if you are using ports-mgmt/poudriere-devel vs. > ports-mgmt/poudriere . Poudriere version reports 3.3.6. I believe it's _not_ the -devel version. > 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've yet to master getting pkg to actually work from a local repository. The handbook says to create /usr/local/poudriere % more /usr/local/etc/pkg/repos/FreeBSD.conf containing FreeBSD: { enabled: no } Hopefully, using pkg install -r /usr/local/poudriere/data/packages/main-default/All [pkgname] will do the trick. Any cautionary tales would be much appreciated. > 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. > If there's a guide to using poudriere/pkg in a self-hosting situation it would be very useful. The existing docs have a very different focus. Thanks again for reading and replying! bob prohaska