From nobody Thu Jun 24 06:02:02 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 6655C11D9F5E for ; Thu, 24 Jun 2021 06:02:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4G9V0104rLz58kl for ; Thu, 24 Jun 2021 06:02:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624514526; bh=OCeoVEmcxeaozxBepyZ0fVjwf0t+Ksv4AkhT7Yj7PaU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GFFm+AWNWi7spWZRzjEpLpJRiX3wq/DxtApHL3KAFl1bGRwQFmQW0IaisAkb2Cch8umY8n/Z2eNKqrFpMClYoQeSSxqPs1+7LazSJ4Bk8/GtEQBSlwg3eRRbHxcDt/OhCBomUWIKQsFsmCt/h1E8dn8QHeo2lWH6tyVo7tDIUNQxkAq6EiN05nG6vcdMZxkHD3/txC8tywA0wEwraGQDs7LgONqmT/IwN4yiPmNT5i/0z5adfVeQjn/YnG5I2iRD2D7IvZ4xWCIp0xy+6WlXTKVrQBFR78QBKJWgIbskxYPeMyJLsySUKBZs5Iwd7/8IaG0p6y5UyhrOfSQcVVwL6g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624514526; bh=APGDAgPXG0KHCh18Xju8q03frQWSmhYBEUgq+krsoeK=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ToXHAb1BMthZTbw7KLytI29KIsXa1aNd3jkQvhlS1FNF/ZB4m466xqGCzfAcONqg9pNxY8NEXJe32xd2Y+nb8k5QsQlQOrUlOM00PIkx9wQwpOpRU+J5F4E/5+El+T7HbrJOuvNVoDQxu4kaoeUQH2pevByuN4XvhgdvzrGkh7VJrBJFwbGTOy8voVwu7evCVjS98ZZnXQcqXtqqSPdR9FszKZ4yyyR4VTwbLqku9LEi9AOSeQvwEcC25sq5LUKkIUcypQbUBusKKktxwz3CIvPtN1sWTlELGKiGaaJ81xrGL7MB+b0xQl0Kqyp+B5uK9WbwhMBkoP+9JiR6Ae3cQg== X-YMail-OSG: imhwGekVM1kUEuzpeqGMD90uJplv__s2I9xrsZQ39qXKAN.I.tDTAlod5xp8VBs CUOoGigvcXr8Q0kbmSmRgRbh_Dn0GdAQmJJgVWR65_WFlf9et0k1Fpa2JjVdQl.Jz34Ucsm6V8UC 4EP4VyFwO6f.6cH.Rn0o2VCeV7PoooIH_At17gJ6.YgoHqvwz.H7yPoTLnqcQpPgCmYu3B1On_a5 iIn4JF_UcHshxeeJ0xAziNm.yJHOK5Gery9YUNIUh8gSnuGs0Lcgh3DIaU6w6QtpHVXxjMk4baTb zD1AcysZHTSXT_wVQC67CTFAr83WPKcgfbJpK0BtQLCFAfgyube5lhmFY0JV.XwXqj3kHn7BVnQz gqYpWiKFFO7_xVY6M7V0wq5g_f76pgLvnbSVPa9yd6qgFxm3ThqWGDbzwFdpNuQ7718hf54jn02e ziHMfWWHFpVKxRQGMf2Scbd4BZ.79e7no_m8l7XftCKu4B3LO_yF0c1lr1.DOc6eomQVJArfOnEN _TJit1f2KpSaMqp_edHvMfeNculwxG4.bdZvicqSjqIx3YS.QcQwO41XGih4hDW9E1uuMDu1kSWn FjPmUlNQfEeAHKAx7zYX5psRRjTJnfHSGIR8jHwv8_kyhxhohYb8tK_o0MrYq_XTSw1P8BX.sSRX cVOjSA87gIu3nWttssyE1NRhmjOhu1IQh2oUVuT.UgFtLmg63SSDePCddXTuLQ1O7KddHcd1oN7B dhtWQ0Mm6mdGtqNSicVfYwbkmIP9iAJMz_YhJHyrZUGvSYgvSOHD_9Huv8V03U6tp7AIhKO7FwF9 T08GCtCJXMZv5njt6s_pLWk4gIp_rJ6MTf0e_bN4wWJZyTcNM87DreVwp7u6vfCsYcjx..RpQF6_ acF54rnqp.x6m1O062zBC9qh3wnqXGMXZCuJzWDk.BGejSY2m7nOpJJ0wLE5GIMH3_c7QJugFSmw AicreeaTttG65JICmjPJn6xH7P1hxB9KJyRJOTCzN3fM0x0ft6qJA_MVNIUZ74AyeIQOQO1XnobM WCY8upG1vV5eWkpAozhidrxyyOqwW9oCvYJmohVaAAkGkS2oMeEUTUMvuceXj571L7blbhJttsqF wDWK1wOjt86Nex7mPlFpvff0CR1bJ7ZWUdUxh8s8gcmWlD8t58Zfd8ux2xKHl1vk6jsIBDQ0gh8d uggEK8mHUWxJsYSZVScB9ic4Fdd8hloRqKk_nZX39byt8QsmIWly8c.W_KyPjyMMQOJhZSsYbvKJ qgwfyzvr.72ttJd8tZ8kg8ubk4mWfIse3Nfb6FfbKW20tZ6HULHgFpgP3zfoWv_KLO17gNHwoaJL r4OYZwNl5qPMywlRRK3fd6L8nnKVWhA5fUaG3NV8QzckL2pSeBk0bQPZnhs6FzfQE_q83VQEvyBS JU4sZYy6h311vsbn_3vOXXuGS8Nn3_jmwbCxQ5H05KTdMtuporQvSyJG6ijI30T4PBnhq8pDE_eX qjVKN8JSC081tBOrJnetD012fxyPZnz5B_u9ajdbs7fo_2ZIZfhHsLHDo3MstrgTxK5HiMNVO5rx Axw.tvI2PRSatB4AknkqChGkxwSHcPdhpzQwys3NotB9MxlktUO4OvLtOgooc3Ggyi_9jVMIz09f bWMyo3nVRKacJmWgGWbrVBq5fPfPKo2Q_sR4QJNZFUVi6mCfEOegtKCY.gJwRqgcs5hMxqoiE8NV UMzql12.JIuPfeQwF1Dpt9HKcAxTTK7iBHDkz_iMnDqrxLaIIwdUouDIrj61VPjsHvDtEWivWZQM xg_MboXJqMGTxHBtoLriMiy0Um3mewnt3iZgueSKwbBDqw1XIjVB723twU2YvN_GbZRzcvqwOc2i G_HflXVicGvxtmOdJkly692AR99AgTWtaUemDXGgsfre5AYR7p6UDNzMJP.8FEXUdy0bNPIw0vl6 Phg8tfPAfATJxINv1j1Da1MNUFQMHMre0vhp8xETHWzyzf4UD5wX5Ru3QVXe9NEfq_ff_0H3043B dN0ImaDs2o7BjmAygQiD93WY30YlZNBkakLIqTPheRvSlXj0wr9j4LEiD90hYExniv4pGxJmUshw wsUXvB_EYmhR5FgQkoXsYAhIgS7DxdmwcQKhv5d3ksR9.OvMSe2QAVX1dU.QtFR8.arWLgqGpIwt JCvJ8Aw3rEFHJf_tloVA8ugL2gDPt9KPwXLI2ALLUTK5yT4fQXu6BBoNRAWfDGVBzfXPKFOefaqG 6Nfiuf3Clkmxq4B.0h9ItpXUE1i8ZIvjWCt0pz8uC8OJ3YyQSJMBuLdVZPZGhzVjMAMqiemyQKza DBaPErjMgd6L82hPTFfFcpDx4oM0SbmWXo8m32rVMIla3Yt2KfCQEV9cbZmpZzWsMGqG2JPLX29Z VSfza3.1m0A1UXHdxm8NoPWg21TlBhbjD.hNGTGEOLSb0gODsUExiy.ivuCX97vwvu6HfNzRKYST xZeeYjphh7xpI7FZzLpsOXrZE62tmXq3RxWma2bSTF0eKCZ_bO5YQkVztcsSsqNKIaANT6kwFJCT M5oFlJiHWNWyFpRPBCVgHJJf6Q9aZdMCibmEKFTCndaWRcrIeN4cUe5rkXLFj0QDEiGUe4SGhZdH KbCvQ7o6yCbQNQsRkNjqHWQ8MXTyM65fIy73WcgKLluIpwmAMkecJItDFPowTfByRbfysRZaCvR0 hJTWXxxwwvZNGlU9J2BBeTxbCjcwEY35pYepNTcsoL3MABwK2WYAZfarGBPFJlw7cnO.8p0uX X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 24 Jun 2021 06:02:06 +0000 Received: by kubenode513.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b3aeda0294369b937aab57148fd682dd; Thu, 24 Jun 2021 06:02:04 +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: <20210624043000.GA87740@www.zefox.net> Date: Wed, 23 Jun 2021 23:02:02 -0700 Cc: FreeBSD ports , freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <22B941CA-3AFF-42FD-98D1-D40EC2F6EC43@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> <8E78EE69-44A2-429E-AB65-941537DE25A0@yahoo.com> <20210624043000.GA87740@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G9V0104rLz58kl 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 21:30, bob prohaska wrote: > On Wed, Jun 23, 2021 at 04:22:35PM -0700, Mark Millard wrote: >> On 2021-Jun-23, at 15:28, bob prohaska wrote: >> . . . >=20 >>=20 > [snipped for brevity] >>=20 >>>> 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. >>=20 > The poudriere session just ended, with a somewhat different error: >=20 > In file included from = /wrkdirs/usr/ports/devel/llvm10/work/llvm-10.0.1.src/lib/Target/AArch64/AA= rch64InstructionSelector > .cpp:312: > lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:41: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > ^ > lib/Target/AArch64/AArch64GenGlobalISel.inc:1900:99: error: expected = expression > /*GIM_CheckRegBankForClass: @0*/, /*MI*/1, /*Op*/2, = /*RC*//*AArch64::FPR64RegClassID: @0*/, > = ^ > 2 errors generated. > [ 25% 1396/5364] >=20 > The last line is included as a fiducial indicator. Two errors instead = of > four, nothing about AMDGPU.=20 You have a prior run that also showed only 2 errors: = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-21= _12h55m51s/logs/errors/llvm10-10.0.1_5.log has: lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, ^ lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc:15822:118: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/0, = /*RC*//*AMDGPU::VGPR_32RegClassID: @2779096485*/, = ^ 2 errors generated. And a prior one that shows 6 errors but for AArch64 instead of AMDGPU: = http://www.zefox.org/~bob/poudriere/data/logs/bulk/main-default/2021-06-18= _19h00m47s/logs/errors/llvm10-10.0.1_5.log has: lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, = /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:3760:117: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/1, /*Op*/1, = /*RC*//*AArch64::FPR64RegClassID: @2779096485*/, = ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:5735:117: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64RegClassID: @2779096485*/, = ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:50: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, ^ lib/Target/AArch64/AArch64GenGlobalISel.inc:22981:119: error: expected = expression /*GIM_CheckRegBankForClass: @2779096485*/, /*MI*/0, /*Op*/1, = /*RC*//*AArch64::GPR64spRegClassID: @2779096485*/, = ^ 6 errors generated. ninja: build stopped: subcommand failed. *** Error code 1 It appears that the bug does not have reproducible details but all of the examples that do not have junk:false show @2779096485 . (And the only junk:false tried so far has @0 instead.) Something is providing and/or using initialized memory. There is the possibility that swapping out and back in is sometimes not provides pages with the intended content. I state that as an example that we really can not claim to know that llvm-tblgen itself is doing something wrong. I'm not claiming to know what is actually happening. But such would fit with contexts that have more RAM that end up avoiding much of the paging/swapping also not seeing the problem. But as in some past examples, you may have exposed a problem with FreeBSD. >> Intersting. I'm unable to see a: >>=20 >> /usr/local/poudriere/poudriere-system/etc/malloc.conf >>=20 >> via what you have published. But I've no clue if such >> an odd symbolic link would be expected to show up. Still true, but . . . Well, now: http://www.zefox.org/~bob/poudriere/ shows a: junk:false Note that this is at the same level as poudriere-system/ is shown. You might want to look and see if the file system shows such a file at that level as well. This did not show up until after the build attempt had finished from what I can tell. > The link seems visible to find and ls:=20 > root@www:/usr/local/poudriere # find . -name malloc.conf > ./poudriere-system/etc/malloc.conf > root@www:/usr/local/poudriere # more = ./poudriere-system/etc/malloc.conf > ./poudriere-system/etc/malloc.conf: No such file or directory > root@www:/usr/local/poudriere # ls -l = ./poudriere-system/etc/malloc.conf > lrwxr-xr-x 1 root wheel 10 Jun 23 14:27 = ./poudriere-system/etc/malloc.conf -> junk:false > root@www:/usr/local/poudriere #=20 >=20 > The link seems invisible to cat and more, reporting "No such file...." The link is looking for a file called junk:false in the same directory. It is not expected to find such a file. > I'm not sure what might be profitably tried next..... Suggestions = welcome! First off, if the point is to get the RPi3B+ going more than it is to get evidence about the problem, I'd suggest booting an RPi4B with the same media (adjusting config.txt as necessary) and trying the build from that boot. If it builds, the media can be moved back to the RPi3B+ for other activity. The failed vs. built status does give some information about the problem. Built would suggest that paging/swapping was involved in the problem. Failed might suggest otherwise. (I do not know if there would be much paging/sapping, depending on how much RAM the RPi4B had.) One experiment would be to use the same boot media on an RPi4B but that had been told in config.txt to limit itself to 1 GiByte of RAM --and to also try with all the RAM being allowed. If the first fails but the second works, that is probably nice evidence. If both fail, that also is probably nice evidence. The other two combinations are less clear what any implications would be. (I'm not claiming that you have such a RPi4B that can be made available for the duration of such experiments.) Another direction is messy: testing under stable/13 and/or releng/13.0 vintages to see if it is somehow specific to main [so: 14], having an analogous context to what is known to fail under main (as much as reasonable). The RPi4B two-RAM-sizes comparison/contrast type of test could also be used. There is also just repeating with junk:false a couple of times to see if there is evidence of variability like there is for without junk:false. Simplest of the suggested tests, but likely the least informative. None of this would be likely to get close to a short, small test that shows the problem. I've no clue how to target that at this point. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)