From nobody Sat Jul 03 21:54:45 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 25C4511F3941; Sat, 3 Jul 2021 21:54:50 +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 4GHQj54rZBz4pLQ; Sat, 3 Jul 2021 21:54:49 +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 163LsjET019522 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Jul 2021 14:54:46 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 163LsjjP019521; Sat, 3 Jul 2021 14:54:45 -0700 (PDT) (envelope-from fbsd) Date: Sat, 3 Jul 2021 14:54:45 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Subject: Re: llvm10 build failure on Rpi3 Message-ID: <20210703215445.GA18768@www.zefox.net> References: <43513842-6FC0-4A89-8F0C-9EB2B328A5ED@yahoo.com> <9CFE71E2-23C3-4072-A8AD-74EDB339A146@yahoo.com> <60EEFD09-97DE-4B4F-BAFD-61B96EF60E27@yahoo.com> <77A35ACF-275F-44C8-AEEE-4EFE5B5CBEA4@yahoo.com> <20210703182546.GA17871@www.zefox.net> <380184FB-6BA1-4C2D-9C6B-E249C2CF1317@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: <380184FB-6BA1-4C2D-9C6B-E249C2CF1317@yahoo.com> X-Rspamd-Queue-Id: 4GHQj54rZBz4pLQ 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 Sat, Jul 03, 2021 at 01:15:19PM -0700, Mark Millard wrote: > > > > So you still have not tried an artifacts or snapshot kernel+world? > Not yet. > > Eventually I resorted to running make in devel/llvm10, to my surprise it > > ran to completion. > > Interesting. > > Was this -j4? -j1? -j2? Any other interesting characteristics > for how it was run? > Nothing special was done. IIRC, it was make -DBATCH > make.log in the background. From top's screen it looked like -j4. > It would be interesting to see if building in a chroot > in that make style also worked (or a non-poudriere jail). > Can you point me to instructions for doing the experiment? > > It also ran make package successfully. Again I tried to > > build just devel/llvm10 using poudriere, again getting "expected expression". > > > > At that point I resized the swap partitions to 1 GB each and tried poudriere > > on devel/llvm10. That got rid of the excessive swap warnings, but didn't help. > > Finally I placed > > MAKE_JOBS_NUMBER=2 > > in /usr/local/etc/poudriere.d/make.conf and tried again. That still failed, > > still with "expected expression". > > I'll note that the running build build shows Load Averages > of under 3. So the MAKE_JOBS_NUMBER=2 seems to be working. > > > Since devel/llvm10 had created a package successfully, I tried slipping a copy > > into poudriere's package directory, hoping it would find and use the package > > to make further progress. Unfortunately, poudriere seems to remember the failure > > and won't use the proffered package. > [large snip which convinced me to give up on tricking poudriere into using a package constructed by make] > > Going in a different direction, one way to force a build to > start over after a failure is to: rm -fr PATH/.building > before starting a new bulk build. This might be appropriate I'm missing something here: what does PATH represent? There's nothing called .building under /usr/local/poudriere, at least after the run finishes. > if one suspects a problem of a kind that did not stop a > build but produced something for a build that fails to operate > correctly. > Such as a corrupt llmv-tblgen? > So lang/rust finished. That is interesting because it includes an > llvm build internally. > Does that build invoke the same llvm-tblgen? [snip] > Again, poudriere does not control memory initialization in > the processes in the builders. > For some reason I got the idea that whatever asked for memory to use was responsible for initializing it. Certainly not the kernel..... > > The fact that the stoppage reported looks like > > a syntax error specific to devel/llmv10 which is unaffected by swap pressure > > makes it seem unrelated to kernel or swap constraints. > > The files with the syntax errors are ones generated by llvm-tblgen > during the build and it is the output of llvm-tblgen that is corrupt, > showing evidence of having used memory not initialized like it should > have been. > Wouldn't that point suspicion at llvm-tblgen, of whatever version LLVM is actually doing the work? > > AIUI, the hardware of the Pi4 is considerably different from the Pi3 in terms > > of memory management, noted from an interview with Eben Upton on YouTube. > > Why would Eben Upton be talking about FreeBSD's memory management? > He was talking about the Pi4 hardware and how it differed from the Pi3 > I suspect that the talk is not about what you think it is about, > but some narrower aspects than the overall memory managment. > I thought it had something to do with added DMA capablity. The video is at https://www.youtube.com/watch?v=hyj-7mTnumI In light of the discussion about llvm-tblgen I'm doubtful it's relevant, but it's not the worst way to waste an hour. > > > Is there any sort of sanity test for the poudriere system? If I delete and > > re-create the existing jail can the existing package library be preserved > > and re-used? If not, that's OK, I'd just like to know beforehand. > > > > # poudriere jail -jNAME -d > # poudriere jail -c -jNAME -m null -M /WORLDPATH -S /SRCPATH -v 14.0-CURRENT > > should work fine. But really all that you are > doing is (using an example from my environment) > is deleting and rewriting a few very small files > in a directory with the jail's name: > So, in my case /usr/local/poudriere/poudriere-system? (using the nomenclature in your sample instructions). That would leave /usr/local/poudriere/data intact.... I'm starting to understand why you think it unlikely to help. > The deletion/replacement of timestamp may have rebuild > consequences from appearing to have changed (or just > being missing). > If timestamps guide decisions on what to make and when, that might be significant. Not sure how I might've screwed them up, but in my hands anything is possible 8-) > Nothing about any of those is going to change how memory > initialization is working in llvm-tblgen's operation > for generating any *GenGlobalISel.inc files, other than > if the timestamp forces some sort of rebuild from scratch > of some build dependencies first. > Maybe this should be obvious, but which llvm-tblgen is in action? the one from the system, (12.0.1) or something else? Thanks for writing! bob prohaska