From nobody Fri Feb 4 04:07:56 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 A535119AAF01 for ; Fri, 4 Feb 2022 04:08:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4Jqhpg4SZlz4jN0 for ; Fri, 4 Feb 2022 04:08:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643947684; bh=IUJN2HmaoqoRyQQpl6wGMfUzxIyQdiv+KMm4O8j4DtY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=iPqZxUo2jawLfQ+KSQix28eGAhxjW4fwjlAIwMwp90ejxyLRItkI1QSdEzWUanmoNeUNKH16FqzY60OKZtZLQY4RA9UcI41mO7YlikUleKTGo0Y74w3mCdrZY9Xe+PAUYLp1OLICOkMRNnYBW9ycuHeYTj79mF5FOo7Cvz7B/FoUf1kQdLmnp4u4p7jc6u397cQ1dNHfjEOK/8UhwClEuNNTjqJ+8bcnkqFaWzDUJmnwhIrHNi8rOt2pheVGjw+tHEWMEVvDGbx7ESd2HYCOK5XELt/7HAtk4nCUp49Gt47cm/9JxHtWwtuU/5NC60nYNc5RIvs4pIUn0JGeIdA9xw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1643947684; bh=up3WKhbePd2w8myAgRp7rH/TJ+vEo1Qgcp4W8Dl17R+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D1OxPfNMlCY3Edf1wAR9mkLvlEVpskrDKTQ+yVAtLRV7yHBCsd4uwuO3gv1c9efW/difVSpLyxJY8zGOePjGJ2Axw4KUxoc63UscD1TRhR8qS1NLf1IsmSHFESWGoaS8EqIXvGW7VQ3migC6z+Xr2G3vEds0EOoP/+65WZuzxyQrXCOOPNSLS9CwVpSdth7x3cR3uppfcCo2tsZ1Q+m5xiYkzpFfdodywGNOZqNnz2o6IIGXk/xXJ3LoZ9XNquITAZcD+u6+ol0FGzhOm4CwqLisYiTjEgiPVt1xj23hXiJSPCrneXtwI6SiXbFNTM25YEDLr15b9/Kcx1LNo8VHbA== X-YMail-OSG: dwTFomsVM1mwlo6v1wP.1S375YKxZE8DnRcA7MQ9WitI_oBuIvRFpTKWPvRRonQ ewYJ5F4_1Gu0b9pl2Xst2WOswAaaYrMzs2dYGMtqwFi3fE7mE0uOF2DSWYm4CbxCtLXpLHdYjz2H vR.f9.vN85zIaW6Cz05JdjN0lOj31MxkYJGs6ivSaK14MKw0oJdNY5.Iy3Ofh4iuyXXMiAXluuEn pzWaJR8NBa9ydiG89oRrI3rxCerfm8UIgTm_K1A.w7NbHq7fWrkwPIp4YLVJwhFitBq7mOVq7MJk tHw2AfruqbyVUwsDtMh4XVFjIBVaSAqYcEoJ3XBL2k6xx38Id923rB7lz.XoIuAPz.WbU60lIDpA plcve3BzENSHv2rNK_MDDbnJHzsxqaAz8averVk2xQMy43.z1oADBaghe7HmVh_AeTG2wgGjzjEp .Owcyr7ncqyYRI3u4jGcLbDJW8EwGKiCzWJ727XzyJGXTpv60lbXM05xjiEcDzA90EhDasfbj2Ai pJzbLy.Iir6NpBZP3n0obmiE5h2_cLVJmHzFN_rQyi_Xww3Xiygo8ihld.aZJ2zzPNjKeQG8Gj9O R.WPT0BUetDIRX1ujq5LC7XijspbnYnmS2X22_EyQkywtNsjy5beo0EgXMnE1Aj_jNLqzqW_B.zm s3HMikrmZuj7I6sJ5fXXL373AB1TVuRRruvqYVXt74C.wPT8IBDxyCTjQd5O7OJM5sL1Bh56fuCt Th2DiosxPV4CftPfnQDdTgTATFONRyiuQortbakQSbd7y.AmEsgMhTuQ6Py080xOeUUBpxLMYeK8 oxpCLoqXjqPEzhoZuAVEYcM.X8s.LidKn4xvwHS24zSTBl4iAYKCr.NDciJkAbWWZi3tukT2S82r T1wrlYYg9knYEmtAf3DeCojATfGBzwL6mTv5Mn.ApMchAUEXPI1T00CDsI2V0.wPx7JbOrCCHjOV O3CJ1txeH853xpDEw6JQDvj9kuuhEwM9q8SBafjsdm4doiqxoSFnPqOw7NhG8PDYWvbAeA4XhmX_ CPu0eNJRqcWUJA9z12CtqwcU.c1UPLPM0n5i0fib2A30d6n6Xf2IM8pGpi4Ua5ZjVCfxUwgptpQL VSFC9gT9fXPD.bU_F0UfKmMbUDY9.wuGYTPTJ0Ai7hOnrM1sIrBT9r9exHIGyAu0HSSIE58KCj9O Eb0nB4FN9QpMN80sUoSvbBIjyFB1rv4fOj7YBAmEIZ1Y3HQW3O1uvT0rTNaUuOovy7X9WO21zNrS rMvne8YA2Y6xvgvlVnWJKCI5G6GgLZSPQyu3yiAxUsqW6ukOqJly3NZyX9y0F3m2Tt5SMkTWUIaR iA4Hmu6XKrBCu5BlFKUXX41YG_Ynh02bkciKbzh4dLahl28EBwKjRigyT5BE79.hrkFJDko48gZR U1cjWrb2cC8j1DgSEioPD1TbZ9NmG9doYhFqPP6Kl7nESIgytbx9iFlu8LhVoWCr3SiHQAx_VpTm NW9xs8oDYH1qfhZQX06N7KxDB5Sv2in5.AqhtXqbuBxm0myK2uz0.a9fb36nZtal8nP4dvwWRgf5 F_i__z6.iS2.chOZEeu4hsQq5PCS5OhURHZW41kpETJF16aF5H9B5t8Ue2MBepfPG_0bSh9YAl2K .d.mHNjpjmk40x3ckBtfq5sayJW8XAAOZvO6TlxgTG5eKqFK02T9L9A1byvnJBnqlK_X.BnNgGyj LJYt3YR0Uh4j2ldj61Iwvd8K7uWGUZONKkOwXKuu1naLX53UJ9.Ka1T5gtckduYkswsvm7WFkIdw DGNjBmFK5WTtrOwzlQLOE6_JT6ApQQxmH2V3hzJ.IebBWqnhFHs4d8GtwPZP25G_ecokBDFv8f8N nVDBUjOMPSfXrmsThTJLj_NIwMuQ5j47bt7QSB9sJLvCikOZBK2pF4plH21zTlXyYNxVgiS_bHyH mqgMYF_w2GM7.y7vtSfttL_zUGkNvKvNOJGzDKVKV8CwbB3ElGxlP0guK.0Qszkve7ELPHwKpMRG TkgOSfikv4_7y.pOaRloOXDoQSjYkQC..kN90iSzJpK.wzImRwBXByiQxKWxryAEEnTbwJnXR2Ur NkM.K0D_Aam4SFG7Xf9aqdci.6AodL5CclYJLEjvjGPfediLSMUNay7MGb76qK9oJcqQKpHuFm2z 9gPTfeiiBt0M_eoHYfuV_azlL65_eETi6JcBYCsK4THxJq2I87V9TnosmnJZNTB10PwpYrb4Jznh B7lXOtMYZ0IGDRzRn6mTfSwC_3IAXKaDHg6N7L9F46kZXWCAScFPJedabGr.ezoQny1G6kUYiEyd x6utwjcmDqPkF X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 4 Feb 2022 04:08:04 +0000 Received: by kubenode550.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ac836916f70751e75e224f4b7fcc19be; Fri, 04 Feb 2022 04:07:58 +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 [problem replicated at last, not analyzed] From: Mark Millard In-Reply-To: <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> Date: Thu, 3 Feb 2022 20:07:56 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F69B8AC-EE36-4FAE-BB46-30127C41E1E4@yahoo.com> References: <8595CFBD-DC65-4472-A0A1-8A7BE1C031D6@yahoo.com> <20220124165449.GA39982@www.zefox.net> <5FAC2B2C-7740-435E-A183-FB3EF1FCE7F9@yahoo.com> <20220202223208.GA78110@www.zefox.net> <70550346-BC53-458F-B01B-68559E5C9847@yahoo.com> <20220203015149.GA78722@www.zefox.net> <8A85F917-F4E8-4382-B777-15AF7401E616@yahoo.com> <20220203230428.GA81336@www.zefox.net> <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jqhpg4SZlz4jN0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=iPqZxUo2; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.08 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.61)[-0.613]; 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(-0.97)[-0.965]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; MLMMJ_DEST(0.00)[freebsd-arm]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 6260 Lines: 190 On 2022-Feb-3, at 19:31, Mark Millard wrote: >> On 2022-Feb-3, at 15:04, bob prohaska wrote: >>=20 >> On Thu, Feb 03, 2022 at 09:17:06AM -0800, Mark Millard wrote: >>>=20 >>> Could you make a copy of the /usr/bin/c++ involved accessible >>> via: >>>=20 >>> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ >>>=20 >>> (possibly compressed)? >>>=20 >>=20 >> Done. >=20 > I was not able to replicate the problem on a RPi4B > with total_mem=3D991 with 2 GiBytes of swap via a > copy of Bob's c++ compiler file. >=20 > BUT . . . >=20 > Using such a c++ copy, I was able to replicate the > problem on the RPi3B with 2 GiBytes of swap. It > had "fault address: 0x1" instead of 0x5 but was > at the same instruction. >=20 > It was the same FreeBSD media for both attempts, > just moved between machines. (The RPi4B uses > the msdosfs on the USB3 NVMe SSD for the RPi* > firmware and U-Boot, not just the FreeBSD > UEFI loader. The RPi3B uses the msdosfs on > a microsd card for the RPi* firmware and > U-Boot but uses the FreeBSD UEFI loader from > the USB3 NVMe SSD.) >=20 > The builds of FreeBSD (mine vs. Bob's) are different > and the specific versions are different. In my tests, > Bob's c++ is using the libraries from my build. >=20 > In my environment, I've replicated the problem using > Bob's c++ in 3 kinds of contexts: >=20 > A) Use of that c++ under main [so: 14]. I should have mentioned that main was a non-debug build (but with symbols: not stripped). > and: > B) Use of that c++ in a stable/13 chroot that I built. I should have mentioned that stabale/13 was a debug build (also: not stripped). > and: > C) Use of that c++ in a stable/13 chroot made via > expansion of the files: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base.txz > = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/arm64/13.0-STABLE/base-dbg.t= xz >=20 > I used the main [so: 14] context for generating the notes > below. >=20 > Bob's c++ does not have symbols (is stripped) and I've > no debug info for Bob's c++. So the failure for a run > under lldb looks like: >=20 > (lldb) run > Process 1094 launched: '/root/c_tests/c++' (aarch64) > Process 1094 stopped > * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) > frame #0: 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > c++`___lldb_unnamed_symbol39489: > -> 0x2df7444 <+40>: ldr x9, [x3] > 0x2df7448 <+44>: cmp x9, #0x8 ; =3D0x8=20 > 0x2df744c <+48>: b.lo 0x2df7ac0 ; <+1700> > 0x2df7450 <+52>: mov x21, x3 > (lldb) bt > * thread #1, name =3D 'c++', stop reason =3D signal SIGSEGV: invalid = address (fault address: 0x1) > * frame #0: 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > frame #1: 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 >=20 > (Absent debug information, the inline information is > not shown. What is shown matches what Bob has reported.) >=20 > For reference: >=20 > (lldb) reg read > General Purpose Registers: > x0 =3D 0x000000004d769800 > x1 =3D 0x0000000050320700 > x2 =3D 0x00000000568aa8c8 > x3 =3D 0x0000000000000001 > x4 =3D 0x0000000000000001 > x5 =3D 0x0000ffffffff9a58 > x6 =3D 0x0000000000000000 > x7 =3D 0x0000000000000000 > x8 =3D 0x238f5fc5e23f2d85 > x9 =3D 0x0000000000000002 > x10 =3D 0x000000000007ffff > x11 =3D 0x0000000000000000 > x12 =3D 0x0000000000000001 > x13 =3D 0x000000004d6f5de0 > x14 =3D 0x0000000000000013 > x15 =3D 0xffffff6bffffffff > x16 =3D 0x0000000005116e70 =20 > x17 =3D 0x0000000049a60dd0 libc.so.7`__free [inlined] = tsd_state_get at tsd.h:212:9 > libc.so.7`__free [inlined] tsd_fast at tsd.h:337:15 > libc.so.7`__free [inlined] free_fastpath at = jemalloc_jemalloc.c:2793:6 > libc.so.7`__free at jemalloc_jemalloc.c:2851:7 > x18 =3D 0xffffffffffffe000 > x19 =3D 0x000000004d769800 > x20 =3D 0x0000000000517f9b =20 > x21 =3D 0x00000000568a9da0 > x22 =3D 0x0000000000000000 > x23 =3D 0x00000000568a8f92 > x24 =3D 0x00000000568aa8c8 > x25 =3D 0x0000000000000002 > x26 =3D 0x00000000568a9da0 > x27 =3D 0x0000000000000001 > x28 =3D 0x0000000000517f94 =20 > fp =3D 0x0000ffffffffa0a0 > lr =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 > sp =3D 0x0000ffffffff9f90 > pc =3D 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > cpsr =3D 0x60000200 >=20 > (x17's information varied across my various experiments. > So it is not obvious that __free being mentioned above > implies much.) >=20 > (lldb) up > frame #1: 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 > c++`___lldb_unnamed_symbol47720: > -> 0x317e784 <+3712>: cbz x23, 0x317e790 ; <+3724> > 0x317e788 <+3716>: ldrb w8, [x23] > 0x317e78c <+3720>: cbnz w8, 0x317e7a8 ; <+3748> > 0x317e790 <+3724>: ldr x1, [sp, #0xc0] >=20 > (That actually points to the line after the jump to > drame #0's subroutine: the return place.) >=20 > (lldb) reg read > General Purpose Registers: > x19 =3D 0x000000004d769800 > x20 =3D 0x0000000000517f9b =20 > x21 =3D 0x00000000568a9da0 > x22 =3D 0x0000000000000000 > x23 =3D 0x00000000568a8f92 > x24 =3D 0x00000000568aa8c8 > x25 =3D 0x0000000000000002 > x26 =3D 0x00000000568a9da0 > x27 =3D 0x0000000000000001 > x28 =3D 0x0000000000517f94 =20 > fp =3D 0x0000ffffffffa550 > lr =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 > sp =3D 0x0000ffffffffa0f0 > pc =3D 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + = 3712 > 20 registers were unavailable. >=20 > For some reason lr was not updated to the > next level of return-place. >=20 >=20 >=20 > I might see about if we can get a build of c++ on > Bob's machine that has symbols not stripped and > has debug information and that also shows the > problem, probably not chaining the optimization > selection. But I'll not deal with that in this > note. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com