From nobody Wed Jun 23 23:22:35 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 C087B5D0D2F for ; Wed, 23 Jun 2021 23:22:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G9K772sMsz4cNc for ; Wed, 23 Jun 2021 23:22:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624490561; bh=EgPVagRXb9V2mkrcE1TOCWW5Qx3LDHWqsK31s87+eEU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ePXEA0OekYD6BtL8nVFmzIZUtSvMhiiu78qSPr5tIRrhU9qqkXxmqvQ5YoBaPA2Ef829WIaJKXJvfsvGdpTaenoc3bABcY6OdIi4/McoxBhFhY7yotmK2u4X7594TJCY4SawUa6Ck2wjvHQGkdZOXhkOE5jQ1BpktW2N+yms4bY5g1xNHwmgOmNxDCVsjfp0+yRhTVEmcrKPFJORFBwtitx/tG1J7wqc7c2inZhfXXnE5ELY08duq+oy6LH/mA43jZFuVLqQL2soWcx42S7clYjBjUAjYp42z8rAP3LXipUBfAJDCL80jtlt+ZMUVX+JXxVPTLyPAl7LqVLygdGPrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624490561; bh=gi2Tzl2StBpWdVxziw/BD4I5u43uAcVNTxzRIT9Gfk+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=B/Pvar4BioYiRFec+JTcqwmHBQ/ztN6xOYStwXFPKPgICp9zrM7z+t/FjdtBZibco0zWh/0btjlWnxTLp5IMzj+z/7bhR/l/lLntu8/c+4VI2ORpCKemsP583tu2zjxq8vxMzoCXgop7iycC0JXC42Bo6SlYOyCIViWBH1/iUfX4pG29j5ViqFE/SphtOPEf5j0TCrYPHG5BCCMvOdKq5Ho0bTPdZ9wEYqErqGPP+TLMjV4Bqe2R7SUuZwgswDZewUc6ePLfTfaJ6zKdSVC2OyhB4C4Nt/fwFGLARZhh7kyVxmf5EEwUbr4clZd3LuR2bbJeCeKAkZZ8Rtu53pQKQw== X-YMail-OSG: e2fobP0VM1mfQkByvmlxNjFk9ACQV1hnI6gIa4nxAPtZbmp.V4W.ralhK2QBeyJ 1j.OAiELYcN8Kyu_DKmfjWjl5lUQezeZCmRZH4Edib1WEPPZh2K9Q8uf97UcZjEW6AH0TDDP2pS0 8I4M3jOXi.ajadhc3WihvWeyt6kiIlygMiWaMWbAQ9mxVotOZTill8dV5SkA7oVOyNtd_IR0Gpig .Vvj6OQQyxaKWedTMgS69299.ZtmkxnZACK9i595IN3ZLvqYDoyGkxUloQwJdknu.ytnPAXkn.SE f2k8VJXB5Yf6.uAABBDErU.3GeZY3DjjOvjgoSRbdkQgwsuSfiznI6IfFi6vKLo2cS516FHVOPoM 51gOaZ0HoKuA66Ol_NEYfhgcT1.IT7ytYkyFlmz9J.YWI.tCq0Y7Xpz1a5pyMBsu9XerxemT.Osm 8SNFduGmTuXZv8AGNOkiM5nEHja6KZ_X3O_Lf.7cw9R3lf8dQ09TvYMkGxtQwZUJCQXUWLlk52It _U9a2VG5vble.Ty5PedVP_hLM4R.JECxwnF1Z9ts2CGTGInfDlcw.wbPP21u0NxINCiYGnTwYH3_ 9W.zOxueFo0ue4azsmc6MeOfEeo5BcNMPGLrRgWbzj1JJAMvrofXmLD4tATVDfRphtMrgV2.BAVh IZYd81nY1avxY1lXmWtpSCKVqCeototgZppTpFN0K0EdIq67lzHuqb.mMSQC5tjr0GnwQeH_AwYM jP3nHVSYv1FcjnCrx5br8beth_f.sBDByTRqKMitSfYlfns.VrjcrgWGnYo3VlSsGmW2mpsMqhpe VwvaZoT2JuOTs7gVw7YB53ojtZPDteqmfxXcA.bliQ9juiah_AByHjsDyJw94gNPmQASaMmbJcBN pv7XVWkPYYaZ4T8TRuOL_Rnq3CZPalgAN9_Q1hIbRPNLoYMFos49BiH71gAd6OgSB6frxktIH9sn NlZwQLYO6bU6E9nFgO_yWjocl5RZY9.cg3ct6xbHrMk9bS7wSVc5ZZurT9PLk.zKoa1nlg6dk3Hy pDenyXNhUmeoetoQfbBwe5FQeaz..ig4zKRhX.4WiFKZ0N5rJWcbg3oDZGWC2NyuzdFkDQVNu2OS Fri4v9rIjXaGzANN0az8I92D3LS695MLm1JDN6lmernoh6suVTZNVsaPq5H4GjGJYv6atBIX7sfy xk7ZdA.wZdKDwZe713ZqnLBhOeXDofCuAPcA7Iy93rWsOEioNIh2TrBOlJjaT6uZoLUhAEmPwSjI LdmsegNU2KB5wgrg1oorgPWbc6ixBsF9dcfAqFl7oeNhFCD7AgC3E_AUtsaHaTaP3fdN5TjFqxol tPeSFe._7D58oAUrjEsjl42IBo9JbIFGBW2SRu7KsUOta9LTnvpT_nJTvXIOA4lOCu0EWPhQZ8Q6 5LWGgJQEkM25UKNV15_FdOHZC0dKfdSljIu3vKGUHr71BU5VlCsh5xWQRNP0.XXgq6gCaEz97Jq_ AR2TQIIpjh9e1oBE0vL_GI3tAwau__fWG.jm4k34nYzeSFVBnFqgM5U1enLZZkQP.leQjfdSQACm BlPoJVr7beo5fJHi6PQJITGDLlJr6Ep2ilwMAsw1aCeE0s72ztZhengZIEi9ayE5ZHSPunGW9A33 LQjRIeJ0Mv5ZJaenD9hS0vfyOjUviygYa0YI7daYFamI1.uOhW8s65amy2pr0DTIYWx7FF6W6lG1 HFFvC1JDSZFgXzKXDEH7jsWBUxhhq8qXkDQFeas5BX3wfeMRKc2sGkENSs3wWWb5Be8K05FMToUY gwoAHbrR5mgK1wIF3pC9wEC7HRtiSqKofsQTIbtQvXZwzn1JxPTziDAbZJMpYrkJLb9_ZnIZ7SRH WUGZ1ueOHC4plRybCQKSHVzEejiaZY3wg4xFl5BJAr6.xZfZcetXePCr5ODs65.CHK2rmR9qKtO0 LQ3arSg2GHZLlXjXoCiK.0ethw4pw.ds.dFx6ZinLz4288tpGVgY0Y_9rqgcUy9s63Fjd1jTMBI4 3wJMSTo8OamQdcZlttj.bjwxnN5vKtSMntzPecZ5Z9IGbkF8RDuHS3X.yOniUt5MjizKKRjZHJFP zaG1HZDy4f_.idtX4wBlX1QZN.cg06hFlMisUosNJUWGSrnKwyBF2Uu4n_SgDQ0GDQTWcjKPC8vh RIH4UyyWjsFvdvYzVaCUqATUNmP0Kk5Mej.V51wEzKeoHbPVBY839k3j50ErJ4clRwdyPlD8T02l Z61nl5VyPvpsX0MVQRRFQaZnS_ur_67Gz9RMPh188NL6qXEUx1Gs6BKrdnoTIZaPC3X7K.E.hQln Yj4qrj0dtfSV6yeeJhsxdEv4QjyZBQt5uXyyZ2zQvoPd.GGHLKgig96uwIIouUohpH7ubCUxO.Pb caDb.mu5n.aIWl2dyDvAOQ6jXQ7z.hjY9q9fyRfz2j05ycKprXTQ0NJNHkqkQd7jA40iQAJR82PE vc6QvU4K2TxY.fnKE.wo8zm5T4P5a6ewHMemtMRjVm9a73CnaQPyYLzeK31RSuk3yaITdo9_qgMK AOkSrPaBNi.5v.b6iqwtEWR4Eq2.qUCkH57fkzUxO6JWrwynEQeyxc..9hk4cMqWA888p44ZvDyX sYQkPrXULOFEJwoZtSeJgaegQxKlyO3YR66DBNtMwe8avkxRpGCAD96Wvw0XpnqIsHn8Emr8iE6v B9RHxKlDuQgKrus6xhRltlbPvL8DsxFSWvjbDSr_4FxgIsvfV6WaYQnwYCwGi_SIPXyUovg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Jun 2021 23:22:41 +0000 Received: by kubenode541.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 8134c30be8b3f4dfd81031bfe68c4232; Wed, 23 Jun 2021 23:22:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: llvm10 build failure on Rpi3 In-Reply-To: <20210623222838.GA85566@www.zefox.net> Date: Wed, 23 Jun 2021 16:22:35 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9K772sMsz4cNc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-ports X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N 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: >>=20 >>> On Wed, Jun 23, 2021 at 01:34:55AM -0700, Mark Millard wrote: >>>>=20 >>>> Not that it helps much, but: 2779096485 =3D=3D 0xA5A5A5A5 >>>>=20 >>>> It appears that such somehow was involved-in/generated by: >>>>=20 >>>> [ 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/AMD= GPUGISel.td --write-if-changed -o = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d = lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d >>>>=20 >>>> and that lead to the commented out notation in the output, with the = "@2779096485" listed in the comment as well. >>>>=20 >>>=20 >>> 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. >>=20 >> 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. >>=20 > The kernel in use is=20 > 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. Side Note: Going in a separate direction: do you also run main on faster aarch64 systems (RPi4B's)? Do you also build there? If so, it is possible to make a copy of the poudriere/data/packages/main-default/ tree from the fast system on the slower system and then use pkg on the slower system without doing builds there. It is also possible to set up to have the fast system be used as a remote source of the packages, much like FreeBSD servers. But I've never done such. Based on what you have done to publish for folks to look at when they are helping, you might (mostly?) already have that set up, other than pointing package to the right URL on the slower machine. End Side Note. >> 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: >>=20 >> 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. >>=20 >> 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. >>=20 >> There is /etc/malloc.conf as a way of controlling the behavior: >>=20 >> ln -s 'junk:false' = /usr/local/poudriere/poudriere-system/etc/malloc.conf >>=20 >> 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. >>=20 > Done and running now. In the interim I tried building llvm10 using > make in /usr/ports, but it failed with another python conflict. 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. >> I do not normally run debug builds and so would not have >> run into 0xA5A5A5A5u from Junk Filling of memory allocations. >>=20 >> 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. >>=20 >>> 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?=20 >>=20 >> I will note that your log file reports: >>=20 >> Host OSVERSION: 1400023 >> Jail OSVERSION: 1400019 >>=20 >> 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: >>=20 >> /usr/local/poudriere/poudriere-system/ >>=20 >> to 1400023 as far as I can tell. >>=20 >=20 > 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.=20 The steps in question for my point are (from your http://www.zefox.org/~bob/readme ): # cd /usr/src # make installworld DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distrib-dirs DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 # make distribution DESTDIR=3D/usr/local/poudriere/poudriere-system = DB_FROM_SRC=3D1 Your: cd /usr/local/poudriere # poudriere ports -c -m null -M /usr/ports # poudriere jail -c -j main -m null -M = /usr/local/poudriere/poudriere-system -S /usr/src -v 14.0-CURRENT leaves /usr/ports/ and /usr/src/ automatically bound to the most recent content from the system. But the installworld related material is not automatic. (And poudriere should not point at the live system's own materials for such: during operation it temporarily changes some things in the system it is pointed at.) >> Separately from that, for poudriere itself: >>=20 >=20 >> I do not know if you are using ports-mgmt/poudriere-devel vs. >> ports-mgmt/poudriere .=20 >=20 > Poudriere version reports 3.3.6. I believe it's _not_ the -devel = version. Okay. I've always used poudriere-devel . No reason that you should but now I know that we can have some distinctions for poudriere itself for recent functionality. >> 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. >>=20 >=20 > I've yet to master getting pkg to actually work from a local = repository. > The handbook says to create=20 > /usr/local/poudriere % more /usr/local/etc/pkg/repos/FreeBSD.conf > containing > FreeBSD: { > enabled: no > } That is part of it. I have: # find /usr/local/etc/pkg/repos/ -print /usr/local/etc/pkg/repos/ /usr/local/etc/pkg/repos/FreeBSD.conf /usr/local/etc/pkg/repos/custom.conf # more /usr/local/etc/pkg/repos/custom.conf=20 custom: { url: = "file:///usr/local/poudriere/data/packages/13_0R-CA72-default", enabled: yes, } The file:// prefix is URL notation and the rest is the directory path, including its leading / . So, for your context: custom: { url: "file:///usr/local/poudriere/data/packages/main-default", enabled: yes, } I'll note that the default for remote use of the FreeBSD servers looks like: # more /etc/pkg/FreeBSD.conf=20 # $FreeBSD$ # # To disable this repository, instead of modifying or removing this = file, # create a /usr/local/etc/pkg/repos/FreeBSD.conf file: # # mkdir -p /usr/local/etc/pkg/repos # echo "FreeBSD: { enabled: no }" > = /usr/local/etc/pkg/repos/FreeBSD.conf # FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } So something somewhat similar likely could be used in /usr/local/etc/pkg/repos/custom.conf to use a faster machine's packages via a slower machine's pkg, without coying over the directory tree that contains the respository. > Hopefully, using=20 > pkg install -r /usr/local/poudriere/data/packages/main-default/All = [pkgname] > will do the trick. Any cautionary tales would be much appreciated.=20 With an appropriate /usr/local/etc/pkg/repos/custom.conf you should be able to use pkg normally. The pkg install -r installs more than needed and not in a way that pkg autoremove would clean up. When you get pkg working with /usr/local/poudriere/data/packages/main-default/ material, you might want to do a round of deleting the installs and then only explicitly installing the things that you directly want to use. The rest needed at run-time should automatically install, but in a way that would allow for a later autoremove to work for things that are no longer being used after an update. >> 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. >>=20 >=20 > 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)