Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
Date: Sat, 20 Jul 2024 21:03:05 UTC
On Jul 20, 2024, at 01:57, Konstantin Belousov <kostikbel@gmail.com> 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