From nobody Wed Jun 23 21:03:42 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 E3C0111D7A0A for ; Wed, 23 Jun 2021 21:03:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 4G9G2v4PVLz3tv6 for ; Wed, 23 Jun 2021 21:03:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624482229; bh=NILNLtxClpNfwhrTl7+Xnux66VUE+BGumvU0XviLHGY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QfZiSnWt8YRFNbT9MEt+w+lCJJNd5iEAzINKFUv2mjLCZvhum/96SSs2WelzXg48Xr5URueFublqduWAu+00eYz4VIm27e3W9IQhIsyPLyvy79Ngm9whPVOda+RC0rCNO/zYWfYJEUxCWG1QG3TzrK7ZuPSUUccEaZU97N3qgvhWRDjsLJOK2ZP9o8UTVcBeqWcIZ9YoLEY3Yt4P08XId7IMexZwOVBy16/SCzpWWrUoMX/Nt3N2YiM/sZtQFI+9wvDL1ablLEE154ze10l6KgoOEjEymQ0Nq41uuFSQwsUetCx6o2y7fX78musg/aGT871MuOCtgrp+ls4ucosypw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624482229; bh=AM3bYhpNnjE4S3hvOWAbK2lC+n1VgM8JZphyn0V2wuf=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=R3mT2mw/0Pi0/jA+lSR4GtsCWUPeak3enN4QUDDZbKZb/x3K0OqBcX1YaHV5uBFvKFUtabHuK4QbR9jz7gYeUu718gOjmb454RnN612bye8Z7dxmoqeCFVoDFmuypRAp33UswHtRUY6J05YiTP8EBVT2Dv63MnvCiWvvgq2ERvMEqw+i+0CMEj9VsM/EUFdR3nAPM5qN+lAWt86M5HqG8OxZ1hsJ1tQEaBjYmN78LBVn2NQL4ccYrvnFz9DjFk4u+Up38wp5BSlWYqck894Lqvc5dxs8DL3mtUiht1wG2OnAEEsJcSDQrYgrljLAuSmuHWSSMI6Ax3Qrpw4AkfKxxQ== X-YMail-OSG: cu9FBsoVM1lgNR_0pKtOpH5m8JbVIvH0Od18vSTJyiBlWUkJeydGe2Umv2Yv6JX k6QZlwjaMMqqp5r2IAnXqvYIjhQcFsZkLOX4KpZTvKunWbkCBhylV6.kXuryc3kE698ar1_JHVji IAs091s26yqb.J5FPpK1SkwZSMifrZEF27C6zxNyszNwBz0FqWoC_qUUM2pFopovWHvPaKWiym7n mNtoH.Fy7gDfWXD3IIdWvR07tTinZuTwBRoqdqCuElPEkuvZftfhRDU7yRCWUA2oGn3mW.Yw7MlY RhtVEzSIwEKjgCs9vp6w3N2LLfk6RmiD2CHSZeYj0.vIbkOuR.RXTNln835YbjMI3KZ5Tg7CJMrt u2CWmhtuVtsws_BZVdEneKx8gQw8MTUtI8J1HtSETgyKM_c9wqzKseEEgohnEIB0Q4urWho87NBd TbHXg_68VoxxWWyUeF3saR7QkXKBuAk8AL1w07f1WkYjKN3QFWuvPGAnbWxBTILUZDOQzsi1N8qp egj1nYxCoLbMtLC_4kbQaIJpj1q6WHYNGwmjZQ3UbUUvFS7flyDWG63u.xku8mHYSMsMG7k345RK HrceKfug6HvpySnMBk.cLzLhmOFvHgZT.cCmdGJ6iW1m6i3o1XechpTasdYiYNrAF43u2F1K43rM gAEUoX68XyAm31G9g637bnyiGSUJJwxY6IMIpd2UOTdr2GbbcjKL5Qd2jHRYba3J7xmMTaAt.gRu UtHdypDyD6T4S.gOabhEeX9mwDwSC2QpgSeVZMjA9fRa8XOVqqlW369DJ9YTRH24p.de4kKIjcLX Eh613nZodTDUsrI95_nxb.DAXZawOQbcHqCPozezavdm9Ip8AkOsttTqBSDlN53ppkRDEhGJddUu VwYp_MOHiNatJz3sbTNqD3MVMdYOb3CvRKDE58L.pQJR2DWNiJ9t4HKlCemgOFpWClZzoAN2dVZl hL4Ag5NbSDUBa2WbD.VfXbv0lItPtCun9SCqFpE3W.vWl1F21aOBfnoMoBifSYdzAsDu_4we8Jiv _bcgIdPCc952Ihuf0j6C89e2EHj7HuLOZtbTvJoPUBtDBVYX3vamD6Ed4S9OWp2S3_KH3NpnUtq4 mJcwKbCWSsdtnpV4kwfaKi0oFqB5Zz46cM7JS9v7Du0AbxUZGEL2E8v8f.OWNtGzdIPrqBjPHwTm cqz3OMxoJVPj_3E77qPIkFbfbVJQWg.3WOsEoy7HcZA2UqIUZxeb2dmlXMjXIQmSvuYzQfBwOMcQ sTaLQ0K3UqI0mpngvR326UHCftgDkRyvD_BxfN2zf42TvNvA65ty47ustkqyV4lqXvYRn3kcIxhB uH8ynQOtxGEM8BnAlvhwYF0w8W0SFqMA5Bi5L5LRii5Ld9qbFFF69L697U3mCl0oP6HUVybhDwCO hXGZFtq0V74_mau3plICzIvpFxMtaAnvTGFREWVdDT6XtJ9wsOwDqmQwwoh9z0sxXqWqVgIcfrC5 lsiL4dX2w40Uu0djpxRqb70DjLGN4.jQ8mmVQxIYY3Tp.DX7jcQBbyOqzSIPTjBIPQDYFsFjEt_d 1Oad759LhQ70zvfOWnsdH1qHIjIGY.GLJxTA8wsFrRsZvJHvVf8RGbl7xtTlsfxqf3l0zRJsJ31V PDtuy8.V2ysBOitFLtSQ_v9Vd_R.uOSsKzw00p8pv0yJmds9PjpvnhsBuL3MMjC4SBT.hMMWSkT8 mPZ_odcCvicN4VkGrllkBz6fuLsCNMlR9EMbXTewJX7ZrS8wFjC.L6xiemqJ8x3ZtcnB_3V4DQyn na_iFmCKCycFO_618R9tqhce59X8QRzA6V2S8PPBcS8QjG7ZRHaVhOgD7J31_1eLqcrREs9Wq4Mk hB8XOC2H4KloO8J3ZykHWaQbcV2qPTfrvJ.DXdUQ6fgpDmUXvPNkeDM_9vmXMvb.r2X2WZDuGHze nzahdZfGyJDRU9e5wQhmaaocjodHYQnxVMbvbJ_aGFRFneAvfvGMQmBxMOZjsrF0uU85A3yZPudY DrwF_.AdCU4nGKdKMqQm1YpQDJ5buecFmo2p4erjpvZXR2eUOTDgORBBn83zcnbyGltYq_uQlwHw h.kvB3RxfJMDY_wHI.FWHTJevJSO6O5ew.JqjcA9_BDMxG_WUE93pdoe49zYHh5ZyoSDnyt02RnT lLEiyDt.i.H2JXwmqewkeHHswcxDBHsa.35hMAh3_1ZALIu1R3k36seEfdN7ncIIW0g3okBZ_Z31 z_2OnuWLceeAMrPqiRUgHwEA6iyWKnKaNbISC51NgIQtqnkgt3CZPig6vt2jCPIORF7fNaFgMRlE 9KrAlNQXecOywI6Wr3vzZpPXIfv1ady6qzflXiZVoqK8osjIdhsnmrFIEh8eP1SzEv4ISav8ByiD csTRLFOmaz9NsEowiJ6QRq5l2VdrKfaIUBKM6h7hvq7DYaJDTcyTHjR3R05Bvt2S65CGAV5Qy9dC g2gd55_5aHZEfQvOMelEnQZ_Ns_W3fri22EHhCLk6t7WnoNvwpwMcCqXmU6wSAasmURJmT1AI85M jjhvz2VbX3Srkh9tH2xoykY.l6ibqZ5Bu2UGJjWvdBHNAPtyPz9nSWdf4VllbBPIE_AcDjwIOySN _fxMgRcg5MSnzF7FmG2kvi3xo6_DtWpCUSRS15uGfX1Ku7hTyhGKHWpqqcm9o2lawVYTeHV3NIXz 5JfjB4s04q_UUP5R2vXo7RVOVorp.Idm_cpbvDk0I8LUoLQJNbNdtieheXD72RYpY9I0p X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 23 Jun 2021 21:03:49 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 319162b11ff0b3ea1d2c9ebd79a66386; Wed, 23 Jun 2021 21:03:45 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: <20210623174338.GA84853@www.zefox.net> Date: Wed, 23 Jun 2021 14:03:42 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> References: <20210623050958.GA79888@www.zefox.net> <20210623174338.GA84853@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9G2v4PVLz3tv6 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 10:43, bob prohaska wrote: > 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. 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. 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 =E2=80=9Calloc=E2=80=9D, each byte of = uninitialized allocated memory will be initialized to 0xa5. If set to = =E2=80=9Cfree=E2=80=9D, all deallocated memory will be initialized to 0x5a. If set to = =E2=80=9Ctrue=E2=80=9D, both allocated and deallocated memory will be initialized, = and if set to =E2=80=9Cfalse=E2=80=9D, junk filling be disabled = entirely. This is intended for debugging and will impact performance negatively. This = option is =E2=80=9Cfalse=E2=80=9D by default unless --enable-debug = is specified during configuration, in which case it is =E2=80=9Ctrue=E2=80=9D 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. 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?=20 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. Separately from that, for poudriere itself: I do not know if you are using ports-mgmt/poudriere-devel vs. ports-mgmt/poudriere . 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 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. But nothing about these is likely to avoid the 0xA5A5A5A5u issue that you ran into. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)