Re: Troubles building world on stable/13 [problem replicated at last, not analyzed]

On 2022-Feb-3, at 19:31, Mark Millard <[email protected]> wrote:

>> On 2022-Feb-3, at 15:04, bob prohaska <[email protected]> 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