From nobody Sat Jun 26 04:41:43 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 D22545D2722 for ; Sat, 26 Jun 2021 04:41:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4GBh6S3MBDz4skn for ; Sat, 26 Jun 2021 04:41:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624682510; bh=zOM4GCNir6DcKKaefpXSp3bQLbwQwCQ45U4F/8VdDSM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z1X3upYwTGtxCJUTMIedH0w0prAuNWaY3OFpThbVMAMxxg9m1PfQOVREb5DxyluunKS8QlO70Tsi1ULt1CObRi+jdk+jsGx+ygY8aiB9OqwFY9GJYZeN6+6J4gajrO/IgclID3N94WejOoiPkfc4zAYspPEnePGRM7yiIsX0ozHSjl2D1bTQBjplMYP9w2N80GKSP8IdlKO3YWB+tUf0Fd0LPPI3/2+AwsnwF3MwNct/TYv91Ze0aBDrCXIWOkJtL8/FZ4waAuRkZVepZKUtcl+sFV+I5VKWkQ4B8CUuNhmMBG3wUP5dpuWzAujhZyShmzYeYTfFMe5TqAsd7JzIHQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624682510; bh=1C5BoyOPwof2qi6Jju8NZuumgH6Q6V4AGypvz7iJgDD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=EB40BeWX378gdxAYqxcXEYo2CIb2Cw3oYZ5yTQ/ftapJQyrinbCbPNrlArh7tiSKg//JQtuk8g2xzrZcdOVBBXHyhfQ89Q+XdYGUUamVdtLh820pgaz5Fm2SgAEfuzsbNkOczBAwDj8wNPMWNJ5FwfjeTs2njf36ni997o7vNPZ7y9fhT+TAFtAd9pXolg165dvE6Zw50lUS6K0rh1cE8TfhEhyeHlpz9Dbkb69I4PZLZi8EUiznjpLNWhvsp8tZNE5oYS+FTF7+fgev8bNZzo81dZfOhGOKF9acD4aOXYBvDllMgDhiWMKUsTAv6gG14qlX7g2q+yLTsSD2wAtvfg== X-YMail-OSG: 6xDBy98VM1kxP5pIfweMXjCnmBZwFug8mfgQ09Otr1tEhXm3XnHtTxHry6bdafW YKM.ykVncOKf.D6KqLY2N2xWdGaCp93Wrlx4anSV6djg.S3GgJ8YszTq0Cy7A.EgL6ymtHKSajWZ VzsZHIRrQ_ALPs4XEH9FEnOszaKRpMHM.NQl4q1Nqh.SxMIXp63y.RW2_9DTJgrBxWz8SFj4B3My nTPxPorFydXnVNTBO6gBV5o7k8YMYAvkGygCnXs9OP1QuS11POIpRCDbR6bFpcqKyty_Z423UPy9 tW1HJC7_8QywekO59lRgCeJqhvfyCU9k3QhaoR3qcTRqU4lO84ix7QQ90hrwLiBkMGq3Ep5PKgud 2x6EiWbDdL.YWeK7mb0IgHmg8cibIKVC.UFeQr1T6lwnGIO.Y.O8j6xLlFAPrFJtBM8ds_HbQb4C GZx885C21J9MzEe4nSQfHAfYttlf8ndpv8hV_f2zLj8CoYXSRwsFncP0EY6Gb7IotorhSoAPI4GX rk6CLHu.AxQHQw3wT5TDUEAuYRGeL9ZhvdR28H.SKLB6vgODRiKGJ3Q64VOF1T7EGxuqHvqCEeKf pCS_aINqGUoZfBiHlz0v7tQj4fhungxrCCbiouJ6llMMFRRLRiBDDJy8FpSEmO48WOtNQSyNOYaq e4Y7GJ7qWA4fIW3.66GIAcjJ7wVrYv3Sakqpe1bQSEwdPszaeRU75mIME6J9rAh4VIlsrnrzFk3R _PIUPpffBmobpMlzIyrAERdWVr1VYRgZwl6APPBJdXQH1Yna8K4yH2lS7SqTyasu7B8H2Mpip4UB 8h8W4dSqhXRyst0GuGsaEHq0rVRC6_5yZ7.cnIMyJUSRLdHPpGfTgSAx95aC7F74TP7b4yj9_4e1 hcaO5s.M1QYvWFS0tFtcfcAHKFwEO5.OPNHE0ZSxdYHrg9DEWtRQYPzTXemZkB1dKFy4IXDccQ6d mpcvrV2JJyU9hp1H7qd8wnyJdLLLp1aW20fmQZg1NvZ2rZlqYU_8AJFQ.6h6CpccHPPg8Voc53mg qxET5ytyjuNUzY_.osWLYmwW0RUpKuX0ABuTu_jpBRU9SaQLxTz1QaIiShgvflMkXMwKkhfEtCMQ 7TJrFOuIU.vKD6VnSyXyzVzvEliemm2sxNSJKKtxYzL3MP_aPOpCfUwRhkc8RBJQhfZqW5elzukQ Q7fF9TpcsOX583oAvYVB3ANHimPM2wtQoigCoKRnfWmeLYBvjPYNOzIRrLAV7HtaLBS5Hhtzz8j_ vmgKyB16XuRIk7KIk1ess1f31exB7ck1DjHSzBhL4QOMI7F92wUfwa_wBRC8Qk2MQ_sHQwSzcEjg YzN8sSPYJCTgctsTnWY9tq_TC9gqJVXntC2lbvN.iJXa3A1TAIX3jp3lj1UywPm2M3SjxtDhtEAj l0NPJyzt4iQUq0gpRDPH1FD6tU_TuStP_U2mbdGIs2pdmAOOYrVpOKjTnjnrcI.4uKZtWRXboWfA BoxFIlo9Jy1TdzyD3hNW1hoP2TJa7bduQWKjbaMnCt4S8EPxS8sVNPY0V0idu3daeh3mub7ODIXG yHeZEMr8LULR9aYUeS8nwRBUwN2x3RYfX8y9W5rGaqbLO_wO_r_.1ttsbL2qLfnpcZvKEuWQ9gEb GXJ3znsKG06GJ14M0EJNcXNVv41biAAXqp.L884Y.VFrpfKlpUUQV1_pjYQINJ4zbu6TMUMsTxyV eL76koqmBx.3kdLgTjomT5B9t9q7pTOtwCr_oKRu3tOq2c9twLbE2fTUHsXXE4gDx.ZJd4tHbOrt _lA3rzeAPb4TenTyajTUVk_jbJRCHdWBKNJuWc0VKJO0NdUwSJUOlRXGIpo60efRJCxxbJM94MXo JWahLo5oDfbPnH.mEJoYOtg9AuxzaiZQ3i.X6O4G0k4IAMLKqNvqHrn2BCP.xKmwDFJbZ8CN31Zl TsEvPnmCNzSrmmYeVLZBqDFJ2CZl3heTBVIzLDkDP4ZPTotMtzge5l_H9uUnBHHOr.aqV2prqQL5 b0BpJTytoffkMlJALbY.zP5no29pHrzbCDWYY31GtRii8pk_r3_7xgBRg9lHNBocpg4T0xvVoZ1d eYx0V011Hkx47pdtpUVQrGHS6aofma4mzizH4JXbvbRxA_NdBIL3mw0ILMmCOwsS1JisnBIYBc26 q8IhfWmjCgwbgu6x8QHIxiYMWM8TTkLk8mhx_2NC3hV.H2w7.I7PeM6.vCzBiXtpwClZTaUxrLxl rhn1m3znndfxCHMbwATj2Zwp.tOXG8cgr0ZcjxMR2BVX39mL2SH.jYgE2om4tcGzNxu5VMoRVhQN yLK6GH5YTO4g1w.k8XY3.vvdr6xIMOuHMlwZSmb5zk_5s942zNqGQ01ExkR2QK1cNxQC3nA8V7in 7T22OTNm1b3dvsMJgRS.GAexJZf9tLvMTfWu0Xx36_5Y1n3i0SdZ3UB.qAVurTGhxveIW1z4Ilr0 Zjgr1ERCiKf5CrxjWZFnJcwHYKxwtY3cAIJxlMFZjGfaFV8nThJ10tsfvvyuuCRtIzmjRszpRy8N DwlkYb0589IIzN6zY1eyibxyZPUYVUBn_CqT2pQIpYOTvF8h8MJXfkI5cpn3eG0tN5RgYr6I_MpH 1EU_P7VWbS4I.DIVGo4txQR7Ensivc._g3YciboqOkhX6k66EUSqNO_BYQp0.dMvUyw8czJ8fCm5 CZgCvOvas7HGexOthc34RI2UxTXAHkMBNz58uO.jHQJtIt1MABMgcNpACdkMnwFbF_eX3mEy3BE3 P9_yhTQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 26 Jun 2021 04:41:50 +0000 Received: by kubenode530.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3951e44e14e145c77bc847ea7989affd; Sat, 26 Jun 2021 04:41:44 +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: <20210626035234.GA18893@www.zefox.net> Date: Fri, 25 Jun 2021 21:41:43 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F0CF2F3-A298-4CEA-AA07-B79810F3E8CF@yahoo.com> <20210623222838.GA85566@www.zefox.net> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@yahoo.com> <20210624160109.GB87740@www.zefox.net> <3B41633E-AAFC-422A-8D73-3B1B001023F0@yahoo.com> <20210625001651.GA98214@www.zefox.net> <5A26965D-2DFD-4A46-A171-A382A61E3CFB@yahoo.com> <20210626035234.GA18893@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4GBh6S3MBDz4skn 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-25, at 20:52, bob prohaska wrote: > On Fri, Jun 25, 2021 at 07:52:32PM -0700, Mark Millard wrote: > [huge snip, hope the quotes are still correct] >>> So I'm going to suggest using an official kernel build >>> as built by the ci.freebsd.org systems, one that is not >>> GENERIC-MMCCAM. In: >>>=20 >=20 > World and kernel are updating now to -current as of yesterday. > I'll replace GENERIC-MMCCAM with GENERIC for simplicity. I still strongly recommend doing some testing of official builds instead of your personal builds. That includes kernel and world, if possible. Until an official build shows the problem, you are not as likely to get the problem worked on. (And, so far, you have the only known context for getting the problem.) >>>=20 >>> I gather that no RPi4B is available to move the media >>> to? (Having more RAM but being able to force much of >>> it to be ignored can be handy as a test environment >>> for this kind of context.) >>>=20 >=20 > It's still patiently chewing away at www/chromium single-threaded. Note that system-clang just got updates for stable/11 stable/12 stable/13 and main for a defect that prevents building www/chromium with a clang that has assertions enabled (a form of debug build contribution): The branch main has been updated by dim: URL:=20 = https://cgit.FreeBSD.org/src/commit/?id=3De7e517981a6591c79fb49cd8810361b0= f3ad5983 commit e7e517981a6591c79fb49cd8810361b0f3ad5983 Author: Dimitry Andric AuthorDate: 2021-06-21 18:46:34 +0000 Commit: Dimitry Andric CommitDate: 2021-06-21 18:48:37 +0000 Fix clang assertion while building recent www/chromium =20 Merge commit c8227f06b335 from llvm git (by Arthur Eubanks): =20 [clang] Don't assert in EmitAggregateCopy on trivial_abi types =20 Fixes PR42961. =20 Reviewed By: rnk =20 Differential Revision:=20 https://reviews.llvm.org/D97872 =20 PR: 256721, 255570 Reported by: jbeich MFC after: 3 days --- contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp = b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp index 60ea1b2af037..f3ab91559d30 100644 --- a/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp +++ b/contrib/llvm-project/clang/lib/CodeGen/CGExprAgg.cpp @@ -2056,7 +2056,7 @@ void CodeGenFunction::EmitAggregateCopy(LValue = Dest, LValue Src, QualType Ty, Record->hasTrivialCopyAssignment() || Record->hasTrivialMoveConstructor() || Record->hasTrivialMoveAssignment() || - Record->isUnion()) && + Record->hasAttr() || Record->isUnion()) = && "Trying to aggregate-copy a type without a trivial = copy/move " "constructor or assignment operator"); // Ignore empty classes in C++. > My mistake, but best to finish what's started.. Now that how to > use the packages created is known they can be tested.=20 >=20 >>=20 >> So: no warning about being mis-tuned vs. the 1 GiByte of >> used RAM. (I do not know about your context for this.) >>=20 >=20 > My Pi3 does report too much swap. But I remain uncertain about > the practical significance of the warning. I gather the issue > is that a certain amount memory is set aside to "index", for > lack of a better word, the data stored in swap. If there's too > much swap relative to index, not all swap can be used. That > seems not much different than running out of swap.=20 You are having problems that are hard to issolate and are also effectively asserting this warning does not indicate an issue that is contributing. If it were me, I'd be trying to find out if the failure can be reproduced when the FreeBSD test involved classifies that no warning is appropriate. >> All the ports that devel/llvm10 needs are already in place >> for poudriere's use for this experiment. I should have mentioned that I have not added any junk:??? controls. And my building in a releng/13 context means that 0xA5A5A5A5u would not be happening on allocation. Stronger: the build context uses my typical forced MALLOC_PRODUCTION style of build. >> Another point is: >>=20 >> # more /usr/local/etc/poudriere.d/options/devel_llvm10/options=20 >> # This file is auto-generated by 'make config'. >> # Options for llvm10-10.0.1_3 >> _OPTIONS_READ=3Dllvm10-10.0.1_3 >> _FILE_COMPLETE_OPTIONS_LIST=3DBE_AMDGPU CLANG DOCS EXTRAS LIT LLD = LLDB LLD_LINK OPENMP PYCLANG BE_FREEBSD BE_NATIVE BE_STANDARD >> OPTIONS_FILE_SET+=3DBE_AMDGPU >> OPTIONS_FILE_SET+=3DCLANG >> OPTIONS_FILE_SET+=3DDOCS >> OPTIONS_FILE_SET+=3DEXTRAS >> OPTIONS_FILE_SET+=3DLIT >> OPTIONS_FILE_SET+=3DLLD >> OPTIONS_FILE_SET+=3DLLDB >> OPTIONS_FILE_SET+=3DLLD_LINK >> OPTIONS_FILE_SET+=3DOPENMP >> OPTIONS_FILE_UNSET+=3DPYCLANG >> OPTIONS_FILE_UNSET+=3DBE_FREEBSD >> OPTIONS_FILE_SET+=3DBE_NATIVE >> OPTIONS_FILE_UNSET+=3DBE_STANDARD >>=20 >> (So I normally build less than BE_STANDARD or >> BE_FREEBSD would build.) >=20 > I'm my own worst enemy when it comes to customization. > The less changed the better 8-) Unless it avoids a problem? (I do it to avoid wasted time.) I'm not claiming it would avoid the problem, but it is one of the things that could be tried to see what happens. >> We will see if this is enough common context to >> replicate the general type of build problem. >> (Your details very from one attempt to the next >> so an exact match need not be expected, even if >> if this does also fail.) >>=20 >=20 > If you replicate the problem I'll be very pleased. > And just slightly relieved. >=20 > My suspcions still center around things I might have=20 > done to corrupt /usr/local/poudriere. Poudriere is not involved in initializing memory for llvm-tblgen's internal memory use. It could be that jails more generally have a problem, not just poudriere ones. But that would be a FreeBSD issue, not a poudriere one. > That leaves > me wondering how to proceed after world, kernel and ports > are updated. Delete /usr/local/poudriere (which would toss > the packages created so far), delete only the jail (not > sure if that'll delete existing packages library) or=20 > something more selective that I don't know about?=20 I see no likely gain from going down this path. Blaming poudriere for lack of memory initialization in llvm-tblgen makes no sense to me at all: poudriere is not involved in that memory allocation or what the bytes are set to before llvm-tblgen get the address of the memory. > The Pi3B is purely experimental, but I'd rather not throw=20 > away usable progress given the extreme slowness of that > progress.=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)