Created attachment 14558 [details]
gdb.log

Hmm, this suggests that gdb may be not wrong:
...
$ for n in $(seq 1 100); do ./outputs/gdb.threads/process-exit-status-is-leader-exit-status/process-exit-status-is-leader-exit-status ; echo $?; done
32
33
32
33
32
32
32
32
32
33
7
32
32
32
33
32
29
32
32
31
32
33
32
33
1
33
33
32
32
32
32
32
32
32
32
32
32
32
32
33
32
32
32
33
32
32
31
33
32
30
32
32
32
33
32
32
32
33
33
32
32
31
32
32
32
32
32
32
33
32
32
32
32
33
33
32
32
32
32
32
32
32
33
32
33
32
32
32
32
33
32
32
32
32
32
32
33
32
33
32
...

In contrast on openSUSE Leap 15.4 I see:
...
$ for n in $(seq 1 100); do ./outputs/gdb.threads/process-exit-status-is-leader-exit-status/process-exit-status-is-leader-exit-status ; echo $?; done
1
  ...
1
$ 
...

Hmm, kernel version 6.1.1.

This linux kernel commit (first include in release v6.1.0) looks interesting:
...
commit d80f7d7b2c75c5954d335dffbccca62a5002c3e0
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Jun 21 14:38:52 2022 -0500

    signal: Guarantee that SIGNAL_GROUP_EXIT is set on process exit
    
    Track how many threads have not started exiting and when the last
    thread starts exiting set SIGNAL_GROUP_EXIT.
    
    This guarantees that SIGNAL_GROUP_EXIT will get set when a process
    exits.  In practice this achieves nothing as glibc's implementation of
    _exit calls sys_group_exit then sys_exit.  While glibc's implemenation
    of pthread_exit calls exit (which cleansup and calls _exit) if it is
    the last thread and sys_exit if it is the last thread.
    
    This means the only way the kernel might observe a process that does
    not set call exit_group is if the language runtime does not use glibc.
    
    With more cleanups I hope to move the decrement of quick_threads
    earlier.
    
    Link: https://lkml.kernel.org/r/87bkukd4tc.fsf_-_@email.froward.int.ebiederm.org
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

...

(In reply to Tom de Vries from comment #0)
> with a revert of
> commit cb25fdbb76e ("gdb: remove assertion in
> psymbol_functions::expand_symtabs_matching") which I expect should not
> matter.

Confirmed, FAILs also reproduce without the revert, so with clean trunk.

First step, filed at https://bugzilla.suse.com/show_bug.cgi?id=1206926

Proposed patch to add xfail here: https://inbox.sourceware.org/gdb-patches/20230908015356.406003-1-simon.marchi@efficios.com/T/#u

The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ea186080fe2b94b21f3ac8ad7941948211d5e67a

commit ea186080fe2b94b21f3ac8ad7941948211d5e67a
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Thu Sep 7 21:53:55 2023 -0400

    gdb/testsuite: add xfail for gdb/29965 in gdb.threads/process-exit-status-is-leader-exit-status.exp
    
    Bug 29965 shows on a Linux kernel >= 6.1, that test fails consistently
    with:
    
        FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=0: continue (the program exited)
        ...
        FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=9: continue (the program exited)
    
    This is due to a change in Linux kernel behavior [1] that affects
    exactly what this test tests.  That is, if multiple threads (including
    the leader) call SYS_exit, the exit status of the process should be the
    exit status of the leader.  After that change in the kernel, it is no
    longer the case.
    
    Add an xfail in the test, based on the Linux kernel version.  The goal
    is that if a regression is introduced in GDB regarding this feature, it
    should be caught if running on an older kernel where the behavior was
    consistent.
    
    [1] https://bugzilla.suse.com/show_bug.cgi?id=1206926
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29965
    Change-Id: If6ab7171c92bfc1a3b961c7179e26611773969eb
    Approved-By: Tom de Vries <tdevries@suse.de>