Date: Thu, 3 Feb 2022 19:31:40 -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: <512F38B3-61FF-401F-87B6-58FEF2DBE74A@yahoo.com> In-Reply-To: <20220203230428.GA81336@www.zefox.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. BUT . . . 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. 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.) 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. In my environment, I've replicated the problem using Bob's c++ in 3 kinds of contexts: A) Use of that c++ under main [so: 14]. and: B) Use of that c++ in a stable/13 chroot that I built. and: C) Use of that c++ in a stable/13 chroot made via expansion of the files: 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 I used the main [so: 14] context for generating the notes below. 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: (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 (Absent debug information, the inline information is not shown. What is shown matches what Bob has reported.) For reference: (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 (x17's information varied across my various experiments. So it is not obvious that __free being mentioned above implies much.) (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] (That actually points to the line after the jump to drame #0's subroutine: the return place.) (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. For some reason lr was not updated to the next level of return-place. 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. =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?512F38B3-61FF-401F-87B6-58FEF2DBE74A>