Re: Troubles building world on stable/13 [problem replicated at last, not analyzed]
- In reply to: Mark Millard : "Re: Troubles building world on stable/13 [problem replicated at last, not analyzed]"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 04 Feb 2022 04:07:56 UTC
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: >> >> On Thu, Feb 03, 2022 at 09:17:06AM -0800, Mark Millard wrote: >>> >>> Could you make a copy of the /usr/bin/c++ involved accessible >>> via: >>> >>> http://www.zefox.net/~fbsd/rpi3/clang_trouble/20220202/ >>> >>> (possibly compressed)? >>> >> >> Done. > > I was not able to replicate the problem on a RPi4B > with total_mem=991 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]. 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: > > 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.txz > > 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 = 'c++', stop reason = 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 ; =0x8 > 0x2df744c <+48>: b.lo 0x2df7ac0 ; <+1700> > 0x2df7450 <+52>: mov x21, x3 > (lldb) bt > * thread #1, name = 'c++', stop reason = 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 = 0x000000004d769800 > x1 = 0x0000000050320700 > x2 = 0x00000000568aa8c8 > x3 = 0x0000000000000001 > x4 = 0x0000000000000001 > x5 = 0x0000ffffffff9a58 > x6 = 0x0000000000000000 > x7 = 0x0000000000000000 > x8 = 0x238f5fc5e23f2d85 > x9 = 0x0000000000000002 > x10 = 0x000000000007ffff > x11 = 0x0000000000000000 > x12 = 0x0000000000000001 > x13 = 0x000000004d6f5de0 > x14 = 0x0000000000000013 > x15 = 0xffffff6bffffffff > x16 = 0x0000000005116e70 > x17 = 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 = 0xffffffffffffe000 > x19 = 0x000000004d769800 > x20 = 0x0000000000517f9b > x21 = 0x00000000568a9da0 > x22 = 0x0000000000000000 > x23 = 0x00000000568a8f92 > x24 = 0x00000000568aa8c8 > x25 = 0x0000000000000002 > x26 = 0x00000000568a9da0 > x27 = 0x0000000000000001 > x28 = 0x0000000000517f94 > fp = 0x0000ffffffffa0a0 > lr = 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 > sp = 0x0000ffffffff9f90 > pc = 0x0000000002df7444 c++`___lldb_unnamed_symbol39489 + 40 > cpsr = 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 = 0x000000004d769800 > x20 = 0x0000000000517f9b > x21 = 0x00000000568a9da0 > x22 = 0x0000000000000000 > x23 = 0x00000000568a8f92 > x24 = 0x00000000568aa8c8 > x25 = 0x0000000000000002 > x26 = 0x00000000568a9da0 > x27 = 0x0000000000000001 > x28 = 0x0000000000517f94 > fp = 0x0000ffffffffa550 > lr = 0x000000000317e784 c++`___lldb_unnamed_symbol47720 + 3712 > sp = 0x0000ffffffffa0f0 > pc = 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. > === Mark Millard marklmi at yahoo.com