Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Jul 2024 14:03:05 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        arm@freebsd.org, current@freebsd.org
Subject:   Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
Message-ID:  <29AD2332-4F1D-4AFD-97F8-633CA3C17179@yahoo.com>
In-Reply-To: <Zpt79jpCFDSiffcy@kib.kiev.ua>
References:  <A3BBDBA3-FF7E-47B8-8B45-C3351918FC08@yahoo.com> <8214703E-AB28-4FB3-A3DD-03C87363D8C6@yahoo.com> <E40B106D-30B7-49DC-8540-911A56E53FCA@yahoo.com> <BFCA474F-78D4-4E98-8A9B-B92C2DB6B0DE@yahoo.com> <E40627DC-35A2-4D5E-A85C-73D7FFD426DF@yahoo.com> <A208F7C8-0D9E-402C-BB85-A5022B37E3EC@yahoo.com> <Zpt79jpCFDSiffcy@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 20, 2024, at 01:57, Konstantin Belousov <kostikbel@gmail.com> =
wrote:

> [Everything and everybody in Cc: are stripped for good].
>=20
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>>=20
>> (gdb) bt
>> #0  0x201aeec0 in __pthread_map_stacks_exec () from /lib/libc.so.7
>> #1  0x2005d1e4 in ?? () from /libexec/ld-elf.so.1
>> Backtrace stopped: previous frame identical to this frame (corrupt =
stack?)
>> (gdb) disass
>> Dump of assembler code for function __pthread_map_stacks_exec:
>> =3D> 0x201aeec0 <+0>: ldr r0, [pc, #8] @ 0x201aeed0 =
<__pthread_map_stacks_exec+16>
>>   0x201aeec4 <+4>: add r0, pc, r0
>>   0x201aeec8 <+8>: ldr r0, [r0, #156] @ 0x9c
>>   0x201aeecc <+12>: bx r0
>>   0x201aeed0 <+16>: andseq r6, r7, r4, lsr #12
>> End of assembler dump.
>>=20
>=20
> Do the following:
> 1. Rebuild rtld/libc/libthr with the debugging info and no =
optimization,
>   i.e. ensure that flags are "-O0 -g" or "-Og -g" and not -O2.  See
>   the first comment in libexec/rtld-elf/Makefile for the hint how to
>   do it.

I got things like:

ld: error: =
/usr/obj/BUILDs/main-CA7-dbg-clang/usr/main-src/arm.armv7/lib/libcompiler_=
rt/libcompiler_rt.a(absvdi2.o) is incompatible with /usr/lib/crti.o
ld: error: =
/usr/obj/BUILDs/main-CA7-dbg-clang/usr/main-src/arm.armv7/lib/libcompiler_=
rt/libcompiler_rt.a(absvsi2.o) is incompatible with /usr/lib/crti.o
. . .

and:

building shared library libthr.so.3
ld: error: =
/usr/obj/BUILDs/main-CA7-dbg-clang/usr/main-src/arm.armv7/lib/libsys/libsy=
s.so is incompatible with /usr/lib/crti.o

and:

ld: error: =
/usr/obj/BUILDs/main-CA7-dbg-clang/usr/main-src/arm.armv7/libexec/rtld-elf=
/rtld_libc.a(sigsetjmp.nossppico) is incompatible with crtbrand.o
ld: error: =
/usr/obj/BUILDs/main-CA7-dbg-clang/usr/main-src/arm.armv7/libexec/rtld-elf=
/rtld_libc.a(lstat.nossppico) is incompatible with crtbrand.o

Attempting a from-scratch buildworld with DEBUG_FLAGS=3D"-Og -g" =
WITHOUT_TESTS=3Dyes
on the buildworld command line ended up using -O2 instead of having -Og =
-g present.

Attempting with a 'env DEBUG_FLAGS=3D"-Og -g" WITHOUT_TESTS=3Dyes' =
command prefix
got the same.

So I'm temporarily using:

diff --git a/share/mk/sys.mk b/share/mk/sys.mk
index 44db9266784f..9c6c7ce575a4 100644
--- a/share/mk/sys.mk
+++ b/share/mk/sys.mk
@@ -145,7 +145,8 @@ CC          ?=3D      c89
 CFLAGS         ?=3D      -O
 .else
 CC             ?=3D      cc
-CFLAGS         ?=3D      -O2 -pipe
+#CFLAGS                ?=3D      -O2 -pipe
+CFLAGS         ?=3D      -Og -g -pipe
 .if defined(NO_STRICT_ALIASING)
 CFLAGS         +=3D      -fno-strict-aliasing
 .endif

for another from-scratch buildworld attempt.

lib/libc/ and lib/libthr/ built without reporting errors
and have -Og -g in the *.meta files that I looked at.
But we will have to see if the rest of the buildworld
makes it through without errors.

> 2. Reproduce the issue under gdb, and backtrace all threads from =
userspace.
>   I only need userspace backtrace, not either kernel-side stacks nor
>   the syscall history.

If the buildworld completes well, it will be a while before
that happens. The installation and testing would then be
later. So it will be a while.

> Are you sure that the issue is specific to armv7, might be it takes =
more
> efforts to reproduce on host native?
>=20

Answered with details earlier.

=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?29AD2332-4F1D-4AFD-97F8-633CA3C17179>