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

> 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].
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.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