Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023

On Jul 20, 2024, at 01:57, Konstantin Belousov <[email protected]> wrote:

> [Everything and everybody in Cc: are stripped for good].
> 
> On Fri, Jul 19, 2024 at 10:38:36PM -0700, Mark Millard wrote:
>> 0x201375c0 - 0x2014092c is .bss in /lib/libthr.so.3
>> 
>> (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:
>> => 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.
>> 
> 
> 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/libsys.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="-Og -g" WITHOUT_TESTS=yes
on the buildworld command line ended up using -O2 instead of having -Og -g present.

Attempting with a 'env DEBUG_FLAGS="-Og -g" WITHOUT_TESTS=yes' 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          ?=      c89
 CFLAGS         ?=      -O
 .else
 CC             ?=      cc
-CFLAGS         ?=      -O2 -pipe
+#CFLAGS                ?=      -O2 -pipe
+CFLAGS         ?=      -Og -g -pipe
 .if defined(NO_STRICT_ALIASING)
 CFLAGS         +=      -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?
> 

Answered with details earlier.

===
Mark Millard
marklmi at yahoo.com