Date: Thu, 3 Feb 2022 20:07:56 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Troubles building world on stable/13 [problem replicated at last, not analyzed] Message-ID: <4F69B8AC-EE36-4FAE-BB46-30127C41E1E4@yahoo.com> In-Reply-To: <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> References: <FA290367-D4B6-463D-AC67-64F224B3C227@yahoo.com> <FBD31544-6D8F-40DB-BC36-F0B2BBA78A14@yahoo.com> <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> <D93232D9-BCBF-4C65-B984-D95CB12ADFCD@yahoo.com> <20220203230428.GA81336@www.zefox.net> <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Feb-3, at 19:31, Mark Millard <marklmi@yahoo.com> wrote: >> On 2022-Feb-3, at 15:04, bob prohaska <fbsd@www.zefox.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F69B8AC-EE36-4FAE-BB46-30127C41E1E4>