From nobody Sun Jan 30 00:15:18 2022 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 28C661980AB1 for ; Sun, 30 Jan 2022 00:15:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 4JmWtW6jNCz4nbK for ; Sun, 30 Jan 2022 00:15:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643501724; bh=3x43zmM99cYAnspFgmg99Fvi2Iy6DtlR4TP/YtSibAM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=OfE4AoEKfZr4nJSkvQJuo+sMNWVIDcge1AtHb2wI0WqbLGyul9K1jp8H44GDB/7TvSCN8rDxn1Y3OcPZ8rv+w2MpUDDOMui2cP2JJebSjj8PIj/6vYkU50ZJO/zLHcpDNZfqixPER5ig3vF2CKHxhCMGEKqKWGUFNKedG/lDc/Y21aLCAztgL9QjyzBgqHoYoN90hnQFyzp+WD5oORiaO1e9QunpE/oyCzCSmIYWVY8TmscTIUsqWNIhoAKArHJBdtQUDuHSQr/t09ZDvXoOHQoVUHkN+H9NfBJy1ipUNo/Qa2c51lwjlTvrjnIhqkulsIrwbI2kXWwhJqUcmiDP1w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643501724; bh=iE/jaEMq0eMvgzBndXRmJwMQ/XBhmITzBaT/c39kdkL=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=k3Ej8As9ueZjP2r1b+nt18aJsrUwM8PrNmhAH9ik56mmrXEcOw4OEyGOfQnbaGS4uyKnbYr7GC8pyHvFvWrxadDgMGS/KLnN8nTiIrdjQFQIitmIlYw83O5xIgdaE+gcyhTTihRAjTRXdKSeN5WPnacXI9C+FfbkJhs50dpSXoSaSjmBkFouKuGXFtv8AcmZitILGHBJj1f6z9tBzmRXjLND4JYtctV4+M1xBtkm3+wh4vpqGvA5bbWzjhmi/lrxwIfajKx4wJ77N2uylbYyMd0MYlrue3aXqMHBZt659iZWeWmK6Muz3Wlrtk4OJwpu9TZiKLwJ1U4NCfmuBIIdUQ== X-YMail-OSG: Q7css18VM1kELolCf3rV0zMrzFZ4o_9qB7DFy09w8Qv56qzIpnPrwAPoy3vN8P1 7R9f6OqGOnTLSED.J8Bq_RV_fw52CWd83U5YtvPJx1E0HIBQ8.efhOttWYRajk6A3QXjXNvFGGSp UcORWzC7ZoYRuEsso7UFrM7I.mrtkz.UHqC6ZFQ_BjnRB5Mhs2p1VYUPBF9.jM.fyNAT9LboBrRC bnBEoRxG1iAx5Zd0cijHvEGWo_KlzOJ12gDZkrHK1aa4azDSz7KgVWRDsoO1HMSkYaPST8vZRebY I7BQtCZjctcTMJZPNtvcF4DOC4AZadK0k7zp7m_gHcId6zSauhR6_OXAZRW_fJDExJ0JmXZc2JPp XUCBA6InfkW5EgSVT1Ya_28qwRrqYjPOShwOc0FUwZ0LbI_VDEMvsuTOqqVBPGgUFumLs_U0BJAH BA.WeSGvC2SqgTa58SHD98QLijeKJaNz3DJZzyjDp0mRhXw3NiVwYjfm_WaKVOHbQMWdfmQkrkFf X4h35QhG0DkwLeR7Z1Pfns0Uuzo7WB4WvZpgdN1kSaB2lycWRUyUYORfa7NHXPtQ.vQeA_6204MZ oEGgsZoSqSX6MhAn3visEWA8F0zx5pP7C6u8RrVD6L9.tlN4ipVHg9Y08zWp7eB3FyF1YYREuaN7 LbMA07B_s9CNa7Q2Le0Rg48tp7VqD2BhxFjz.6UXRu1hN4HJPvnAj4PQNiVm1NECZcrDkJ8..oWR GxiSndD2chNAPoiAxmtLvXhlkzmlKAhm1_U1YFIuSNn6Au8vbv4bsHSm6acnbK0D2XH29zUXkBiW 7EkJlwO.wGO1nXcbWo_bb0fhidjn1E8rD29RQirC8WkKH2RKHFzf9GtIgC14GgcI5bB1czi2OzxW hZvy06Rmx3ozHgJHw.dlpByOsRK72_fiqHoQ.kRT7LhCmFmeY1hHcxgLovA10mmKcunGCz2Io4F0 bfiM01UvmemlgzflegKNELJkQVkWSL8aSceAw2Qonz19S5KtCOqF6X2dUOQ5IFxpaloUZgmV871F 7PUu4DqZR_H.2sug2MSbS6U_RHP30d3YC5GoDeFmM_tPq.QWBq_napZ6OYX2Ku_Uh.gW294v255T DBMn6pXzrkhopiIRxDncUI_csZYUY58iP7Rl6Mbo9ca7OaupqhaGZUXTyhORjJjYmwCXLoAA6xd8 v1cXzee.pyrWiADF1TU275roJGJhP4VGcPi..1ep_zcDcs0fM8b7p3VsInFBReQrSQ_RXTnLP4N1 oechs51I7PvBqyROD_BgSQIiZS6eWtxUo4hY.Ea0bwpVvr5VOVmiPNgqVBPZonWC1qdiFrh10jwl KgDp55bZBaOV5qM2hukN2ZSLbP5yIHVeMH0UAdUaXoo925XqZ9TbzHFfhoGz80v7ohPoeJDkeLz4 i2RdZhdpJiGNKz8q12Z9wqkmkuOS4hRPPlnlkKTd8..NiljWF0dLFx2tyda4W8PyqkwWjq2IW1NF HzT9gchVCqW.UUvApEbCdTH9KbJOIlyjBu9xpGyD8zxbpFRMRZQ4upYMx2DGwKlK6zP7pmt_g2Ei A7tQo8A02qL.WH4WF.oqW9QLBBeW.g_B7a3YBnGGkB_3Xq0SbSL0c8Xej.dsD9iEZtgAH.hst4Hy 1t3Bm9c0.3HNQLFCUjaHUN8lh5VZlaGJLp3rThYq9WFKSgyiUUiw3TVhopDMuHmgm.o8aRB91zG0 l7LqyyNuwBSjLjAG8vliKUd6R3qjiHIOTc9MZTW8hQaZ4TpQCRt10LnSKd0xxoJDCiEhV36mDjIc 38NibugKqgo4ar5tm5PNSocA6tYXGpYW7tTl9MTOldMLD_SXBPsetEGrkuYdGaXp4uOAEAMuMJjR FN4S7hHTSI41wVVI8rDohguOp0yoM30lQKYjd9TVDxdEJLfCyWyp7nwapS3jQOm5XiO1Wd2RqaLO diqwfIf98WWTHSyZtkVX7eEmnFNRAMqBYh8G8obbY3SEYrpxFpJO9lA11bdUQHqFGmFJNXuN6nFg UUH1KO6QKtYOL5xqxZs0pTU18zGpmNSurQctgF6On2TGym26.s0s.7wP9x.jbJlCU3Lk3ZzaN1mx pnDuxf6kv0bg4cNoMSzqNXQb2iX12vlpnJfBXvzhOfhcqN2sLSTrSwT1yr.f82iYVxii2bkaMfmp 1tpzpAa.ArU7HDJGu0NedHa4eItP3qhSkhQl_m7OH7E8zU8fjBEbCllfOFN8qSCSYTdCYyDPNkGf I0AeymMeLHOlsqklN4TS2ZKDADTMiFC3TJPS1Uxid1QqD4u6C15JdPb14EO36PLN7SgIU5MXehNh ZzQSb9hCezAlBnw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 00:15:24 +0000 Received: by kubenode523.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b82c1ca1036730db1eed890c5d80df1c; Sun, 30 Jan 2022 00:15:20 +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.120.0.1.13\)) Subject: Re: Troubles building world on stable/13: here, gmock_main-f5c28a.cpp built fine with no swap enabled From: Mark Millard In-Reply-To: <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> Date: Sat, 29 Jan 2022 16:15:18 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <1CB4EDCD-0998-4363-8CEA-14854EB76FA3@yahoo.com> <20220125162245.GA43635@www.zefox.net> <61A3CF79-552C-4884-A8EA-85003B249856@yahoo.com> <20220125180823.GB43635@www.zefox.net> <35046946-7FE4-4E44-950F-BF9CCA72D8F0@yahoo.com> <20220125221753.GA44654@www.zefox.net> <58DF1E04-98F4-496C-AFEC-B80EADFF8A74@yahoo.com> <2F856AEE-F580-4578-BA45-16849769AD18@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmWtW6jNCz4nbK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=OfE4AoEK; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-28, at 22:43, Mark Millard wrote: > An FYI: I do not have problems building gmock_main-f5c28a.cpp --even > with no swap at all on an RPi3B: >=20 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/gpt/RPi3Bswp2g 2097152 0 2097152 0% > # swapoff /dev/gpt/RPi3Bswp2g > # swapinfo > Device 1K-blocks Used Avail Capacity > # ./gmock_main-f5c28a.sh > # ls -Tldt gmock_main-f5c28a* > -rw-r--r-- 1 root wheel 134840 Jan 28 22:02:09 2022 = gmock_main-f5c28a.o > -rwxr-xr-x 1 root wheel 4509 Jan 21 23:26:29 2022 = gmock_main-f5c28a.sh > -rw-r--r-- 1 root wheel 7044253 Jan 21 23:26:29 2022 = gmock_main-f5c28a.cpp >=20 > You could try such on other aarch64 RPi*'s and see if > any of them require swap space to do the compile. (The > same for any other example .cpp and .sh pairs.) My > expectation is that you will find that they do not > require any swap space be enabled. >=20 > This is main [so: 14] instead of stable/13 . My only > stable/13 environments at this point are bectl (so > under ZFS). I do not not try to use ZFS with less than > 8 GiBytes of RAM: default configuration instead of > tailoring for smaller amounts of RAM. >=20 > But I've also built under stable/13 (with ZFS involved). > top did not show the build of the .o using significant > memory under stable/13. >=20 > Part of the point of the .cpp that the compiler generated is that > it uses no include files: everything is expanded inline for > the source code. Thus, no other c++ source file should be involved. > I got the copy from where you posted it. That it builds in my > context indicates that it is unlikely for your or my copy of the > source code to be corrupted. >=20 > That leaves basically compiler binaries (and supporting files) as > potential sources of variation, possibly via corruption. (This > was only the production of a .o file. Fewer toolchain programs > are involved.) >=20 >=20 > For reference . . . >=20 > Under main [so: 14] (UFS context example): >=20 > # c++ -v > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) > Target: aarch64-unknown-freebsd14.0 > Thread model: posix > InstalledDir: /usr/bin >=20 > Under stable/13 (ZFS and bectl context example): >=20 > # c++ -v > FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) > Target: aarch64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin >=20 > So, for as much as the compiler identifies its own content, they > are supposedly the same, other than having a different default > Target FreeBSD variant. (But I do not expect that the compiler > identifies something unique to the combination of FreeBSD specific > patches or other FreeBSD choices that are involved.) A potential source of variability in the llvm part of buildworld results is if LLVM assertions are enabled vs. disabled. My buildworlds are based, in part, on: MALLOC_PRODUCTION=3D WITH_MALLOC_PRODUCTION=3D WITHOUT_ASSERT_DEBUG=3D WITHOUT_LLVM_ASSERTIONS=3D But you report a mix of results on your systems. Might you have a mix of (implicit?) WITH_LLVM_ASSERTIONS=3D vs. WITHOUT_LLVM_ASSERTIONS=3D FreeBSD builds across your systems where you tried the .sh on the .cpp file? Similar points could be questioned in other buildworld results for (implicit?) WITH_ASSERT_DEBUG=3D vs. WITHOUT_ASSERT_DEBUG=3D use for the builds. But this seems unlikely to lead to llvm-specific behavioral differences. =3D=3D=3D Mark Millard marklmi at yahoo.com