From nobody Sun Jan 30 01:10:42 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 C30CB1973311 for ; Sun, 30 Jan 2022 01:10:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4JmY6S1mvlz3hLM for ; Sun, 30 Jan 2022 01:10:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643505049; bh=0JMathyNV3tXJj3seTBHBM9GY6H6PcrpTPagw56g46g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=g7M6iGwTg2Q9cOYe9CVh3oP2BHYCWgDaublpmu7IqEICFDMcSnx2o/1hEmGQn1Ndc0OiizYhXW3fSUlm+Eu5NVxQ55IJrRirJdrSh6EeIXiojMdKHwmEmsCkqp5e1frUCHGTT0ikhASetwX7F+GGiJiR4g1eHgDuNotu7kCLcRJukP4xzbAO4/qrlOtvkMTOSpeBLVfwzGGk2cj5rQlkTG+BhwVzQMmAZA6Oen9QrDyHmGONwFgBkzw5zdgu+popoTyeeEYGxbL53Plz7XbhWkUUF/sxP7YqgVAa/k0NJSI9/ESoMV+rIy/xJmur/WCtGixja7Nclff5dKFN9bBWrw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643505049; bh=1bnKkmqWxHbMY9CWhQkBOVNFWjDS7ecmeV+N8AWFt1k=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iNjVvQyWuxKnZlW+dGERBVMIPLZt2P908mqioKc39X04LMyn16iPwcoPfzIxtPihhHZqZ0vCiC2POgrxL6NaHKe7oMN4gUHK1YOBAlzLyPM3YUZe4HAhA0bsupgS8nIryKGu7paDFPSh2LWEOSpZU57tm//VQIi9wQw/7hcGGPGcw1fJoEBDALdlo3oPf/JGX9V9XlAg4lREYhsPuUHxAbcrwTskobyJeMUYGh8de0W2C5IDs8OPs1tK6sSg6QqsjpFBA/8V/ccTIDGUg/wWdC478z7gQ0/PJpjGsD6RwAk69twyJrunDBfnQVKq82Oek0/KDzWDq593XXpHC/koLA== X-YMail-OSG: xl.AzGsVM1lprJtIe9nSbCFdZpQrc1cVBfUXUxe1.Oj8GFXNwaBmvSmUDi4f3VH KXAMOVgVTPKDWBnBl8_dRjetuwhu8wwLs9Jwjm6t5ukzMXMQ05N7nG04Rv07A.bSQnBSiqu8aypL 8Wfo8jnc9KdXXfV7l5B4Ev5zb32WD0pEJjjNVnZNaI2D8xE06aPOJKIyleWfIIBcmUBdSUNsegY_ g.2AJqoj1qLcfekgUWeVBXpOptQqUWmi.IvwmFCrNF8us.h_wmAcBXUfhqiJNoR.RcG7ejD3a5e2 XmePujgArhEeLBmxJ5MPMRY14IOGs8CjoxMAN6z7j31YGdeBxoMlIEuRHh9TUa8Wpav29bNgNc1N OacxwKCKIEFLCWV9Mu1SQPQVvmTJtbJzHcJpB32Uou28YntpJvNG1mLYFfaRLlZVy8iY9rroBjxT DMpOJ64CaraVEtxZ7_MtcrtrBhgBQkcBxXT.rxIk0OmSAhwi3L6ILDjcRmo70dcXxXpR2k8VKW3e 5DKd10hJ86nICw8YMyTdj_.N34b2qtba9GlenGyKEimSQ3XOWTtKcnoS2SD.hxJf14R8FhyFFQYA BZmo4liylkhFl1vSMlnegwbHO9H6vIqAVlkouMbvnVEW.BlLEWA3eXweWGjDhg7HnUZlvvGDS4MM tmvBs6tyUXtFZp7yEO7GxQLqjTCW_kraOJl0pq29wU9KlnDjF1echNhaAn2FrK.X7i61YPv4N0rR OZ_9c27eQCCfllIBt2D7qkbRfXhJbQioyiwNByet0oN2tW22WStE1IljzSfSk7eXzQz5nh2KxOA7 nfjLSyEItTOX.Yr__vxyzHjhM05JL4UaK7NOKu74PKwl7hHX_iH5oluv39mkAifO0p17pVAPhKvl 06OreCycw3mi0aaQyOlfXRnEVxSEkMF693lEcqs_b9Exxr4oTa76iqQBide.NPT4LZi6mZzgVlew QAZM4XIhIxkH1rdQZKzUlYNm6Fq9V8C8JE6r.mz82tWrhUokwGxcCJCZpcXkGnf816vnc9IImQ9v a.Fl34iNm4WSrNq10VFuvZrrQlLRmZ0oSXji8rhIIUvtrRgObYHAPKpd2dqyAvmzNgor5TwYjt8I or7JL2ywKuAM4_RPk6huEa1PTPohMByClawd04ajk1t5YszdE_pf97Dokfxe9c.SecdDWetyDwvz SauVSNEIGWn7g9YaUu3nn31D3RPth6uFU32V23YF2rPCr10zCLns49r554mPaVvioprt0wmyOxXF H2pAmCKF8Gadu35ISxIPMFD7KjTxbb9X08s.tMWUDRRiQXh8lJu4SgxgFqr6Dyd0WHt7z0KiEMYx a82rv_TWiFFMMazSO.8GSGG0cUu66EQP_wzEC6MFmQ1oKHJF1j88pnefx0c1hA3HRKYZ_BXIzflA ODVWkzOOtePa_XqXinbH0wY3IDmtq.5o9so1yZYdPh54FMoB3QJnFjieExjOq7ZvOHdVPvd4_p47 3Sqt2FkQsllt95Z0HzqE92zRYUc0MClmDFwAG.0qoIg8.GpFpgFvfYG057yJNZOmIOrZhCmwWYAn Heg3VzeanfhdrR0Xq9SlZMT1SjYTYQMICpoBu0QAqhsXHoCZKVgiV9jjvZf.OlBhkorRzma8tCDd vx73U01PSQY8Iw_hH3hpcIRM0kgbnw21vDvZxCofWav3gxZXeY18s25XGWmkw.2pg6z3Nl.2BBfM 4sEQwubLQp8Tn63ScQTleJCdAm8BYeulx.s8AI4ZR9Owics7nJSyei19ny0u3zD_4YrkpmoOmYxV ZWehsGfpklwjHV5PvDDQZmjtKA5I5zz0.EAHszuvsQEY9F2LHAjXOO4qPDNhlrNpx9VZF80t0hQb mGC3RxyBUmr41aWNSTKTOvwG0XwnPBJQjQGyS0KWj0iNOZ6yYim2gtQEKt4C0O8plu1EXwwPZizB 1HggpTyaSDjbay1Ope.N_Wo_qLZC_xIVZT9LwyKgtqcbYR_W5SOrq.GyBrKvFpa_r67ZTcqu33iY .wbx4yzxPJvc1UG3WQuEI5Jw4F0XT33qZCF9MaeHfwpMxXMchbHYOZebbhmwrY6MgBTZKWn393g2 mhzQqgQfawaQawMW8s8KivkiYI6V5WR24.08uT_iqtmU7sji7G5UOkNSTpclhKzmDlrDqiq4GoM9 FI3fMpfmdcar.qiyOdIRp8P4vNI0Bi0UFEVTpwt9fvulshI2x_0BUKreB8UzW_MkR3Odhmw08kYq Lqp2mUYk1QOwk.KHMXGdZTF6v.J.tqF1O3P8lrxyaw6nv5tiP3ByMIElnlXEMDr7ec2xWX3oge_q OrCmiYeqvZH5rtjY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 30 Jan 2022 01:10:49 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 876fa21ded261a605871eacbd2b48fef; Sun, 30 Jan 2022 01:10:45 +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: <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> Date: Sat, 29 Jan 2022 17:10:42 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <1EAE4B42-32D2-486C-BD9A-D133CF0B8293@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> <3F827F7E-E6AA-45BA-89B6-1B9CA5D0593B@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JmY6S1mvlz3hLM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=g7M6iGwT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.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]; 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_SPAM_SHORT(1.00)[1.000]; 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.31:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jan-29, at 16:15, Mark Millard wrote: > On 2022-Jan-28, at 22:43, Mark Millard wrote: >=20 >> 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.) >=20 > 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: >=20 > MALLOC_PRODUCTION=3D > WITH_MALLOC_PRODUCTION=3D > WITHOUT_ASSERT_DEBUG=3D > WITHOUT_LLVM_ASSERTIONS=3D >=20 > 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? >=20 > 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. I set up and tried a context that was using WITH_LLVM_ASSERTIONS=3D and the .sh based build of the .cpp I have still worked (no swap space active). =3D=3D=3D Mark Millard marklmi at yahoo.com