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

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

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