Hello Yury,

Yury Khrustalev via linaro-toolchain <[email protected]> writes:

>> From: Christophe Lyon <[email protected]>
>> Sent: 20 October 2025 12:21 PM
>> To: Yury Khrustalev
>> Cc: [email protected]
>> Subject: Re: [Linaro-TCWG-CI] glibc-2.42.9000-284-g27effb3d50: 9 regressions 
>> on aarch64
>> ...
>> > Can I ask, which version of qemu was used for this build? does it support 
>> > SME?
>>
>> This build didn't use qemu. it was executed on a graviton 3 instance.
>> 
>
> There are QEMU variables in the make check command...
> In any case, I cannot reproduce these failures, all relevant tests work 
> correctly on both
> FVP and hardware aarch64 system.

Sorry for the delay. It took me a bit to reproduce it outside of our CI
environment because I'm not used to glibc development, but I finally
managed it on a QEMU VM with -cpu max running Ubuntu 24.04:

1. Build glibc and install according to 
https://sourceware.org/glibc/wiki/Testing/Builds#Building_glibc_with_intent_to_install

2. Change GDB testcase to wait for GDB to be attached:

--- a/gdb/testsuite/gdb.threads/foll-fork-other-thread.c
+++ b/gdb/testsuite/gdb.threads/foll-fork-other-thread.c
@@ -22,6 +22,7 @@
 #include <errno.h>
 #include <assert.h>
 #include <limits.h>
+#include <stdio.h>
 
 /* Set by GDB.  */
 volatile int stop_looping = 0;
@@ -66,6 +67,13 @@ main (void)
   int i;
   int ret;
   pthread_t thread;
+  volatile int gdb_attached = 0;
+
+
+  printf ("PID = %d\n", getpid ());
+
+  while (gdb_attached == 0)
+    sleep_a_bit ();
 
   alarm (60);
 

I'm attaching the full .c file, to simplify things.

3. Build testcase according to
https://sourceware.org/glibc/wiki/Testing/Builds#Compile_against_glibc_in_an_installed_location:

$ SYSROOT=/path/to/glibc-install
$ gcc -L${SYSROOT}/usr/lib64 \
      -I${SYSROOT}/include \
      --sysroot=${SYSROOT} \
      -Wl,-rpath=${SYSROOT}/lib64 \
      -Wl,--dynamic-linker=${SYSROOT}/lib/ld-linux-aarch64.so.1 \
      -g \
      -pthread \
      -o foll-fork-other-thread \
      -DFORK_FUNC=fork \
      foll-fork-other-thread.c

4. Create the following GDB commands file:

$ cat gdb-commands.txt
set libthread-db-search-path /path/to/glibc-install/lib64
frame function main
set gdb_attached = 1
set displaced-stepping auto
catch fork
continue
thread 1
set scheduler-locking on
break foll-fork-other-thread.c:85
continue
set scheduler-locking off
delete breakpoints
set follow-fork child
next
bt

5. Run the testcase and attach GDB to it (you can use the distro's GDB):

$ ./foll-fork-other-thread &
[1] 32660
PID = 32660
$ gdb -p 32660 -x gdb-commands.txt
Attaching to process 32660
Reading symbols from 
/home/bauermann/scratchpad/GNU-1706/foll-fork-other-thread...
Reading symbols from /home/thiago.bauermann/tmp/glibc-install/lib64/libc.so.6...
Reading symbols from 
/home/thiago.bauermann/tmp/glibc-install/lib/ld-linux-aarch64.so.1...
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/home/thiago.bauermann/tmp/glibc-install/lib64/libthread_db.so.1".
__internal_syscall_cancel (a1=a1@entry=0, a2=a2@entry=0, 
a3=a3@entry=281474087606464, a4=a4@entry=0, a5=a5@entry=0,
    a6=a6@entry=0, nr=nr@entry=115) at cancellation.c:40

⚠️ warning: 40  cancellation.c: No such file or directory
#5  0x0000aaaabcdf0dac in main () at foll-fork-other-thread.c:76
76          sleep_a_bit ();
Catchpoint 1 (fork)
[New Thread 0xffffacf0f1a0 (LWP 32682)]
[Switching to Thread 0xffffacf0f1a0 (LWP 32682)]

Thread 2 "foll-fork-other" hit Catchpoint 1 (forked process 32683), arch_fork 
(ctid=0xffffacf0f270)
    at ../sysdeps/unix/sysv/linux/arch-fork.h:41
⚠️ warning: 41  ../sysdeps/unix/sysv/linux/arch-fork.h: No such file or 
directory
[Switching to thread 1 (Thread 0xffffad0fdf60 (LWP 32660))]
#0  __syscall_cancel_arch () at 
../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S:50
⚠️ warning: 50  ../sysdeps/unix/sysv/linux/aarch64/syscall_cancel.S: No such 
file or directory
Breakpoint 2 at 0xaaaabcdf0e0c: file foll-fork-other-thread.c, line 85.

Thread 1 "foll-fork-other" hit Breakpoint 2, main () at 
foll-fork-other-thread.c:85
85            sleep_a_bit ();    /* break here */
[Attaching after Thread 0xffffacf0f1a0 (LWP 32682) fork to child process 32683]
[New inferior 2 (process 32683)]
[Detaching after fork from parent process 32660]
[Inferior 1 (process 32660) detached]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/home/thiago.bauermann/tmp/glibc-install/lib64/libthread_db.so.1".
⚠️ warning: Not resuming: switched threads before following fork child.
[Switching to Thread 0xffffacf0f1a0 (LWP 32683)]
arch_fork (ctid=0xffffacf0f270) at ../sysdeps/unix/sysv/linux/arch-fork.h:41
⚠️ warning: 41  ../sysdeps/unix/sysv/linux/arch-fork.h: No such file or 
directory
#0  arch_fork (ctid=0xffffacf0f270) at ../sysdeps/unix/sysv/linux/arch-fork.h:41
#1  __GI__Fork () at ../sysdeps/nptl/_Fork.c:33
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

The "corrupt stack" error above is the detected regression.

I reproduced the problem also on today's trunk (commit
013f5167b9c0). Commit b4b713bd8921 (the parent of your commit) doesn't
reproduce the problem. Here is the backtrace from it:

#0  arch_fork (ctid=0xffffa806f270) at ../sysdeps/unix/sysv/linux/arch-fork.h:43
#1  __GI__Fork () at ../sysdeps/nptl/_Fork.c:33
#2  0x0000ffffa81297ec in __libc_fork () at fork.c:75
#3  0x0000aaaacaf20bc0 in gdb_forker_thread (arg=0x0) at 
foll-fork-other-thread.c:35
#4  0x0000ffffa80f09cc in start_thread (arg=0x0) at pthread_create.c:448
#5  0x0000ffffa814f94c in thread_start () at 
../sysdeps/unix/sysv/linux/aarch64/clone3.S:72

Looking at frame #1 from trunk shows:

(gdb) info frame 1
Stack frame at 0xffffacf0e7a0:
 pc = 0xffffacfc52b8 in __GI__Fork (../sysdeps/nptl/_Fork.c:33); saved pc = 0x0
 called by frame at 0xffffacf0e7a0, caller of frame at 0xffffacf0e7a0
 source language c.
 Arglist at 0xffffacf0e770, args:
 Locals at 0xffffacf0e770, Previous frame's sp is 0xffffacf0e7a0
 Saved registers:
  x19 at 0xffffacf0e780, x20 at 0xffffacf0e788, x29 at 0xffffacf0e770

Notice how it says "saved pc = 0x0". That doesn't look good.

Compare with frame 1 from the parent commit b4b713bd8921, which has a
good backtrace:

(gdb) info frame 1
Stack frame at 0xffffa806e7a0:
 pc = 0xffffa812526c in __GI__Fork (../sysdeps/nptl/_Fork.c:33); saved pc = 
0xffffa81297ec
 called by frame at 0xffffa806e8d0, caller of frame at 0xffffa806e7a0
 source language c.
 Arglist at 0xffffa806e770, args:
 Locals at 0xffffa806e770, Previous frame's sp is 0xffffa806e7a0
 Saved registers:
  x19 at 0xffffa806e780, x20 at 0xffffa806e788, x29 at 0xffffa806e770, x30 at 
0xffffa806e778

Notice that it has a valid "saved pc". Also interesting is the list of
saved registers, which includes x30 (aka the link register).

-- 
Thiago


_______________________________________________
linaro-toolchain mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to