[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-arm
Subject: Re: Troubles building world on stable/13 [problem replicated at last, not analyzed]
From: Mark Millard <marklmi () yahoo ! com>
Date: 2022-02-04 4:07:56
Message-ID: 4F69B8AC-EE36-4FAE-BB46-30127C41E1E4 () yahoo ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic