Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH v2 44/47] Add gdb.threads/leader-exit-schedlock.exp
Date: Mon, 19 May 2025 14:23:05 +0100	[thread overview]
Message-ID: <20250519132308.3553663-45-pedro@palves.net> (raw)
In-Reply-To: <20250519132308.3553663-1-pedro@palves.net>

This adds a new test for letting the main thread exit the process with
scheduler-locking on, while there are other threads live.

On Linux, when the main thread exits without causing a whole-process
exit (e.g., via the main thread doing pthread_exit), the main thread
becomes zombie but does not report a thread exit event.  When
eventually all other threads of the process exit, the main thread is
unblocked out of its zombie state and reports its exit which we
interpret as the whole-process exit.

If the main-thread-exit causes a whole-process exit (e.g., via the
exit syscall), the process is the same, except that the exit syscall
makes the kernel force-close all threads immediately.

Importantly, the main thread on Linux is always the last thread that
reports the exit event.

On Windows, the main thread exiting is not special at all.  When the
main thread causes a process exit (e.g., for ExitProcess or by
returning from main), the debugger sees a normal thread exit event for
the main thread.  All other threads will follow up with a thread-exit
event too, except whichever thread happens to be the last one.  That
last one is the one that reports a whole-process-exit event instead of
an exit-thread event.  So, since programs are typically multi-threaded
on Windows (because the OS/runtime spawns some threads), when the main
thread just returns from main(), it is very typically _not_ the main
thread that reports the whole-process exit.

As a result, stepping the main thread with schedlock on Windows
results in the main thread exiting and the continue aborting due to
no-resumed-threads left instead of a whole-process exit as seen on
Linux:

(gdb) info threads
  Id   Target Id                                    Frame
* 1    Thread 11768.0x1bc "leader-exit-schedlock"   main () at .../gdb.threads/leader-exit-schedlock.c:55
  2    Thread 11768.0x31e0 (in kernel)              0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 11768.0x2dec "sig" (in kernel)        0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 11768.0x2530 (in kernel)              0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 11768.0x3384 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  6    Thread 11768.0x3198 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 11768.0x1ab8 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 11768.0x3fe4 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  9    Thread 11768.0x3b5c "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 11768.0x45c "leader-exit-schedlock"   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 11768.0x3724 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 11768.0x1e44 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  13   Thread 11768.0x23f0 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  14   Thread 11768.0x3b80 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
(gdb) set scheduler-locking on
(gdb) c
Continuing.
[Thread 11768.0x1bc exited]
No unwaited-for children left.
(gdb) info threads
  Id   Target Id                                                     Frame
  2    Thread 11768.0x31e0 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 11768.0x2dec "sig" (exiting)                           0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 11768.0x2530 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 11768.0x3384 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  6    Thread 11768.0x3198 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 11768.0x1ab8 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 11768.0x3fe4 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  9    Thread 11768.0x3b5c "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 11768.0x45c "leader-exit-schedlock" (exiting)          0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 11768.0x3724 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 11768.0x1e44 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  13   Thread 11768.0x23f0 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  14   Thread 11768.0x3b80 "leader-exit-schedlock" (exiting process) 0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll

The current thread <Thread ID 1> has terminated.  See `help thread'.
(gdb)

The "(exiting)" and "(exiting process)" threads are threads for which
the kernel already reported their exit to GDB's Windows backend (via
WaitForDebugEvent), but the Windows backend hasn't yet reported the
event to infrun.  The events are still pending in windows-nat.c.

The "(exiting process)" thread above (thread 14) is the one that won
the process-exit event lottery on the Windows kernel side (because it
was the last to exit).  Continuing the (exiting) threads with
schedlock enabled should result in the Windows backend reporting that
thread's pending exit to infrun.  While continuing thread 14 should
result in the inferior exiting.  Vis:

 (gdb) c
 Continuing.
 [Thread 11768.0x31e0 exited]
 No unwaited-for children left.
 (gdb) t 14
 [Switching to thread 14 (Thread 11768.0x3b80)]
 #0  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
 (gdb) c
 Continuing.
 [Inferior 1 (process 11768) exited normally]

The testcase continues all the (exiting) threads, one by one, and then
finally continues the (exiting process) one, expecting an inferior
exit.

The testcase also tries a similar scenario: instead immediately
continue the (exiting process) thread without continuing the others.
That should result in the inferior exiting immediately.

It is actually not guaranteed that the Windows backend will consume
all the thread and process exit events out of the kernel before the
first thread exit event is processed by infrun.  So often we will see
for example, instead:

(gdb) info threads
  Id   Target Id                                                     Frame
  2    Thread 11768.0x31e0 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 11768.0x2dec "sig" (exiting)                           0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 11768.0x2530 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 11768.0x3384 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  6    Thread 11768.0x3198 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 11768.0x1ab8 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 11768.0x3fe4 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  9    Thread 11768.0x3b5c "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 11768.0x45c "leader-exit-schedlock"                    0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 11768.0x3724 "leader-exit-schedlock"                   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 11768.0x1e44 "leader-exit-schedlock"                   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  13   Thread 11768.0x23f0 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  14   Thread 11768.0x3b80 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll

Above, we can't tell which thread will get the exit-process event,
there is no "(exiting process)" thread.  We do know it'll be one of
threads 10, 11, and 12, because those do not have "(exiting)".  The
Windows kernel has already decided which one it is at this point, we
just haven't seen the exit-process event yet.

This is actually what we _always_ see with "maint set target-non-stop
off" too, because in all-stop, the Windows backend only processes one
Windows debug event at a time.

So when the the test first continues all the (exiting) threads, one by
one, and then when there are no more "(exiting)" threads, if there is
no "(exiting process)" thread, it tries to exit the remaining threads,
(in the above case threads 10, 11 and 12), expecting that one of those
continues may cause an inferior exit.

On systems other than Windows, the testcase expects that continuing
the main thread results in an inferior exit.  If we find out that
isn't correct for some system, we can adjust the testcase then.

Change-Id: I52fb8de5e72bc12195ffb8bedd1d8070464332d3
---
 .../gdb.threads/leader-exit-schedlock.c       |  56 +++++
 .../gdb.threads/leader-exit-schedlock.exp     | 215 ++++++++++++++++++
 2 files changed, 271 insertions(+)
 create mode 100644 gdb/testsuite/gdb.threads/leader-exit-schedlock.c
 create mode 100644 gdb/testsuite/gdb.threads/leader-exit-schedlock.exp

diff --git a/gdb/testsuite/gdb.threads/leader-exit-schedlock.c b/gdb/testsuite/gdb.threads/leader-exit-schedlock.c
new file mode 100644
index 00000000000..25492f6c0a7
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/leader-exit-schedlock.c
@@ -0,0 +1,56 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2025 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+#include <pthread.h>
+#include <assert.h>
+#include <unistd.h>
+
+static pthread_barrier_t threads_started_barrier;
+
+static void *
+start (void *arg)
+{
+  pthread_barrier_wait (&threads_started_barrier);
+
+  while (1)
+    sleep (1);
+
+  return NULL;
+}
+
+#define NTHREADS 10
+
+int
+main (void)
+{
+  int i;
+
+  pthread_barrier_init (&threads_started_barrier, NULL, NTHREADS + 1);
+
+  for (i = 0; i < NTHREADS; i++)
+    {
+      pthread_t thread;
+      int res;
+
+      res = pthread_create (&thread, NULL, start, NULL);
+      assert (res == 0);
+    }
+
+  pthread_barrier_wait (&threads_started_barrier);
+
+  return 0; /* break-here */
+}
diff --git a/gdb/testsuite/gdb.threads/leader-exit-schedlock.exp b/gdb/testsuite/gdb.threads/leader-exit-schedlock.exp
new file mode 100644
index 00000000000..a2745a22613
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/leader-exit-schedlock.exp
@@ -0,0 +1,215 @@
+# Copyright (C) 2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# On Linux, exiting the main thread with scheduler locking on results
+# in an inferior exit immediately.  On Windows, however, it results in
+# a normal thread exit of the main thread, with the other threads
+# staying listed.  Test this, and then test iterating over all the
+# other threads and continuing then too, one by one, with
+# scheduler-locking on.  Also test schedlock off, for completeness.
+
+standard_testfile
+
+if {[build_executable "failed to prepare" $testfile $srcfile {debug pthreads}]} {
+    return -1
+}
+
+# Run "info threads" and return a list of various information:
+#
+#  Element 0 - the highest numbered thread, zero if no thread is found.
+#  Element 1 - the "(exiting process)" thread, zero if not found.
+#  Element 2 - a list of "(exiting)" threads.
+#  Element 3 - a list of the other threads.
+
+proc info_threads {} {
+    set highest_thread 0
+    set exit_process_thread 0
+    set exit_thread_threads {}
+    set other_threads {}
+    set any "\[^\r\n\]*"
+    set ws "\[ \t\]*"
+    set eol "(?=\r\n)"
+    set common_prefix "^\r\n(?:\\*)?${ws}($::decimal)\[ \t\]*${::tdlabel_re}${any}"
+    gdb_test_multiple "info threads" "" -lbl {
+	-re "${common_prefix}\\(exiting process\\)${any}${eol}" {
+	    set highest_thread $expect_out(1,string)
+	    verbose -log "\nhighest_thread=$highest_thread, exiting process\n"
+	    set exit_process_thread $highest_thread
+	    exp_continue
+	}
+	-re "${common_prefix}\\(exiting\\)${any}${eol}" {
+	    set highest_thread $expect_out(1,string)
+	    verbose -log "\nhighest_thread=$highest_thread, exiting thread\n"
+	    lappend exit_thread_threads $highest_thread
+	    exp_continue
+	}
+	-re "${common_prefix}${eol}" {
+	    set highest_thread $expect_out(1,string)
+	    verbose -log "\nhighest_thread=$highest_thread, other thread\n"
+	    lappend other_threads $highest_thread
+	    exp_continue
+	}
+	-re "^\r\n$::gdb_prompt $" {
+	    verbose -log "\nhighest_thread=$highest_thread, prompt\n"
+	    gdb_assert {$highest_thread > 0} $gdb_test_name
+	}
+    }
+    verbose -log "info_threads: highest_thread=$highest_thread"
+    verbose -log "info_threads: exit_thread_threads=$exit_thread_threads"
+    verbose -log "info_threads: other_threads=$other_threads"
+    verbose -log "info_threads: exit_process_thread=$exit_process_thread"
+
+    return [list \
+		$highest_thread \
+		$exit_process_thread \
+		$exit_thread_threads \
+		$other_threads]
+}
+
+# If EXIT-THREADS-FIRST is true, continues all threads which have a
+# pending exit-thread event first, before continuing the thread with
+# the pending exit-process event.
+proc test {target-non-stop exit-threads-first schedlock} {
+    save_vars ::GDBFLAGS {
+	append ::GDBFLAGS " -ex \"maintenance set target-non-stop ${target-non-stop}\""
+	clean_restart $::binfile
+    }
+
+    set is_windows [expr [istarget *-*-mingw*] || [istarget *-*-cygwin*]]
+    set is_linux [istarget *-*-linux*]
+
+    if {!$is_windows && ${exit-threads-first}} {
+	# No point in exercising this combination because we will
+	# return before we reach the point where it is tested.
+	return
+    }
+
+    if ![runto_main] {
+	return
+    }
+
+    gdb_breakpoint [gdb_get_line_number "break-here"]
+    gdb_continue_to_breakpoint "break-here" ".* break-here .*"
+
+    gdb_test_no_output "set scheduler-locking $schedlock"
+
+    # Continuing the main thread on Linux makes the whole process
+    # exit.  This makes GDB report all threads exits immediately, and
+    # then the inferior exit.  The thread exits don't stay pending
+    # because Linux supports per-thread thread-exit control, while
+    # Windows is per-target.
+    if {!$is_windows || $schedlock == off} {
+	gdb_test_multiple "c" "continue exit-process thread to exit" {
+	    -re -wrap "Inferior.*exited normally.*" {
+		pass $gdb_test_name
+	    }
+	    -re -wrap "No unwaited-for children left.*" {
+		# On Linux, GDB may briefly see the main thread turn
+		# zombie before seeing its exit event.
+		gdb_assert $is_linux $gdb_test_name
+	    }
+	}
+
+	return
+    }
+
+    # On Windows, continuing the thread that calls TerminateProcess
+    # (the main thread when it returns from main in our case) with
+    # scheduler-locking enabled exits the whole process, but core of
+    # GDB won't see the exit process event right away.  Windows only
+    # reports it to the last thread that exits, whichever that is.
+    # Due to scheduler locking, that won't happen until we resume all
+    # other threads.  The TerminateProcess-caller thread gets a plain
+    # thread exit event.
+    gdb_test "c" "No unwaited-for children left\\." "continue main thread"
+
+    if {${target-non-stop} == "on"} {
+	# With non-stop. GDB issues ContinueDebugEvent as soon as it
+	# seens a debug event, so after a bit, the windows backend
+	# will have seen all the thread and process exit events, even
+	# while the user has the prompt.  Give it a bit of time for
+	# that to happen, so we can tell which threads have exited by
+	# looking for (exiting) and "(exiting process) in "info
+	# threads" output.
+	sleep 2
+    }
+
+    with_test_prefix "initial threads info" {
+	lassign [info_threads] \
+	    highest_thread \
+	    exit_process_thread \
+	    exit_thread_threads \
+	    other_threads
+
+	gdb_assert {$highest_thread > 0}
+    }
+
+    # Continue one thread at a time, collecting the exit status.
+    set thread_count $highest_thread
+    for {set i 2} {$i <= $thread_count} {incr i} {
+	with_test_prefix "thread $i" {
+	    lassign [info_threads] \
+		highest_thread \
+		exit_process_thread \
+		exit_thread_threads \
+		other_threads
+
+	    # Default to a value that forces FAILs below.
+	    set thr 0
+	    # Whether we expect to find a thread with "(exiting process)":
+	    #   0 - not expected - it's a failure if we see one.
+	    #   1 - possible - we may or may not see one.
+	    #   2 - required - it's a failure if we don't see one.
+	    set process_exit_expected 0
+
+	    if {$i == $thread_count} {
+		set thr $highest_thread
+		set process_exit_expected 2
+		gdb_test "p/d \$_inferior_thread_count == 1" " = 1" "one thread left"
+	    } else {
+		if {${exit-threads-first} && [llength $exit_thread_threads] != 0} {
+		    set thr [lindex $exit_thread_threads 0]
+		} elseif {$exit_process_thread > 0} {
+		    set thr $exit_process_thread
+		    set process_exit_expected 2
+		} elseif {[llength $other_threads] != 0} {
+		    set thr [lindex $other_threads 0]
+		    set process_exit_expected 1
+		}
+	    }
+
+	    gdb_test "thread $thr" \
+		"Switching to .*" \
+		"switch to thread"
+	    gdb_test_multiple "c" "continue thread to exit" {
+		-re -wrap "No unwaited-for children left\\." {
+		    gdb_assert {$process_exit_expected != 2} $gdb_test_name
+		}
+		-re -wrap "Inferior.*exited normally.*" {
+		    gdb_assert {$process_exit_expected != 0} $gdb_test_name
+		    return
+		}
+	    }
+	}
+    }
+}
+
+foreach_with_prefix target-non-stop {off on} {
+    foreach_with_prefix exit-threads-first {0 1} {
+	foreach_with_prefix schedlock {off on} {
+	    test ${target-non-stop} ${exit-threads-first} $schedlock
+	}
+    }
+}
-- 
2.49.0


  parent reply	other threads:[~2025-05-19 13:40 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-19 13:22 [PATCH v2 00/47] Windows non-stop mode Pedro Alves
2025-05-19 13:22 ` [PATCH v2 01/47] Make default_gdb_exit resilient to failed closes Pedro Alves
2025-05-19 13:56   ` Andrew Burgess
2025-06-06 13:56     ` Pedro Alves
2025-05-19 13:22 ` [PATCH v2 02/47] Add test for continuing with some threads running Pedro Alves
2025-05-21 19:36   ` Kevin Buettner
2026-04-02 13:07     ` Pedro Alves
2025-05-19 13:22 ` [PATCH v2 03/47] infrun: Remove unnecessary currently_stepping call Pedro Alves
2025-05-21 19:44   ` Kevin Buettner
2026-04-02 13:17     ` Pedro Alves
2025-05-19 13:22 ` [PATCH v2 04/47] infrun: Split currently_stepping, fix sw watchpoints issue Pedro Alves
2026-04-02 13:33   ` Pedro Alves
2025-05-19 13:22 ` [PATCH v2 05/47] thread_info::executing+resumed -> thread_info::internal_state Pedro Alves
2026-04-06 18:01   ` Pedro Alves
2025-05-19 13:22 ` [PATCH v2 06/47] Windows gdb: Dead code in windows_nat_target::do_initial_windows_stuff Pedro Alves
2025-05-19 13:22 ` [PATCH v2 07/47] Windows gdb: Eliminate global current_process.dr[8] global Pedro Alves
2025-05-28 19:09   ` Tom Tromey
2026-04-06 19:44   ` Pedro Alves
2025-05-19 13:22 ` [PATCH v2 08/47] Windows gdb+gdbserver: New find_thread, replaces thread_rec(DONT_INVALIDATE_CONTEXT) Pedro Alves
2025-05-19 13:22 ` [PATCH v2 09/47] Windows gdb: handle_output_debug_string return type Pedro Alves
2025-05-19 13:22 ` [PATCH v2 10/47] Windows gdb: Eliminate reload_context Pedro Alves
2025-05-19 13:22 ` [PATCH v2 11/47] Windows gdb+gdbserver: Eliminate thread_rec(INVALIDATE_CONTEXT) calls Pedro Alves
2025-05-19 13:22 ` [PATCH v2 12/47] Windows gdb+gdbserver: Eliminate DONT_SUSPEND Pedro Alves
2025-05-19 13:22 ` [PATCH v2 13/47] Windows gdb+gdbserver: Eliminate windows_process_info::thread_rec Pedro Alves
2025-05-19 13:22 ` [PATCH v2 14/47] Windows gdb: Simplify windows_nat_target::wait Pedro Alves
2025-05-28 19:16   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 15/47] Windows gdb+gdbserver: Move suspending thread to when returning event Pedro Alves
2025-05-28 19:17   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 16/47] Windows gdb: Introduce continue_last_debug_event_main_thread Pedro Alves
2025-05-28 19:18   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 17/47] Windows gdb: Introduce windows_continue_flags Pedro Alves
2025-05-19 13:22 ` [PATCH v2 18/47] Windows gdb: Factor code out of windows_nat_target::windows_continue Pedro Alves
2025-05-19 13:22 ` [PATCH v2 19/47] Windows gdb: Pending stop and current_event Pedro Alves
2025-05-19 13:22 ` [PATCH v2 20/47] Windows gdb+gdbserver: Elim desired_stop_thread_id / rework pending_stops Pedro Alves
2025-05-30 20:41   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 21/47] Windows gdb+gdbserver: Introduce get_last_debug_event_ptid Pedro Alves
2025-05-28 19:21   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 22/47] Windows gdb: Can't pass signal to thread other than last stopped thread Pedro Alves
2025-05-28 19:22   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 23/47] Windows gdbserver: Fix scheduler-locking Pedro Alves
2025-05-30 20:37   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 24/47] Windows gdb: Enable "set scheduler-locking on" Pedro Alves
2025-05-19 13:22 ` [PATCH v2 25/47] Windows gdbserver: Eliminate soft-interrupt mechanism Pedro Alves
2025-05-19 13:22 ` [PATCH v2 26/47] Windows gdb+gdbserver: Make current_event per-thread state Pedro Alves
2025-05-28 19:30   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 27/47] Windows gdb+gdbserver: Make last_sig " Pedro Alves
2025-05-28 19:31   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 28/47] Windows gdb+gdbserver: Make siginfo_er " Pedro Alves
2025-05-28 19:33   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 29/47] Add backpointer from windows_thread_info to windows_process_info Pedro Alves
2025-05-19 13:22 ` [PATCH v2 30/47] Windows gdb+gdbserver: Share $_siginfo reading code Pedro Alves
2025-05-19 13:22 ` [PATCH v2 31/47] Windows gdb+gdbserver: Eliminate struct pending_stop Pedro Alves
2025-05-28 19:36   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 32/47] Windows gdb: Change serial_event management Pedro Alves
2025-05-28 19:37   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 33/47] Windows gdb: cygwin_set_dr => windows_set_dr, etc Pedro Alves
2025-05-19 13:22 ` [PATCH v2 34/47] Windows gdb: Avoid writing debug registers if watchpoint hit pending Pedro Alves
2025-05-30 20:43   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 35/47] Windows gdb+gdbserver: Check whether DBG_REPLY_LATER is available Pedro Alves
2025-05-19 13:22 ` [PATCH v2 36/47] linux-nat: Factor out get_detach_signal code to common code Pedro Alves
2025-05-28 19:44   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 37/47] Windows GDB: make windows_thread_info be private thread_info data Pedro Alves
2025-05-28 19:52   ` Tom Tromey
2025-05-19 13:22 ` [PATCH v2 38/47] Introduce windows_nat::event_code_to_string Pedro Alves
2025-05-28 19:53   ` Tom Tromey
2025-05-19 13:23 ` [PATCH v2 39/47] Windows gdb: Add non-stop support Pedro Alves
2025-06-05 16:21   ` Tom Tromey
2025-05-19 13:23 ` [PATCH v2 40/47] Windows gdb: Eliminate invalidate_context Pedro Alves
2025-05-28 19:54   ` Tom Tromey
2025-05-19 13:23 ` [PATCH v2 41/47] Windows gdb: Watchpoints while running (internal vs external stops) Pedro Alves
2025-05-30 20:50   ` Tom Tromey
2025-05-19 13:23 ` [PATCH v2 42/47] gdb_test_multiple: Anchor prompt match if -lbl Pedro Alves
2025-05-21 15:19   ` Tom de Vries
2025-05-27 22:41     ` Pedro Alves
2025-05-27 23:20       ` Pedro Alves
2025-05-28 11:59         ` [PATCH v2] of " Pedro Alves
2025-06-05 16:37           ` Pedro Alves
2025-06-05 17:20             ` [PATCH v3] " Pedro Alves
2025-06-06  9:58               ` Tom de Vries
2025-06-06 13:53                 ` Pedro Alves
2025-05-19 13:23 ` [PATCH v2 43/47] Windows gdb: extra thread info => show exiting Pedro Alves
2025-05-28 19:58   ` Tom Tromey
2025-05-19 13:23 ` Pedro Alves [this message]
2025-05-29 16:09   ` [PATCH v2 44/47] Add gdb.threads/leader-exit-schedlock.exp Tom Tromey
2025-05-19 13:23 ` [PATCH v2 45/47] infrun: with AS+NS, prefer process exit over thread exit Pedro Alves
2025-05-19 13:23 ` [PATCH v2 46/47] Windows gdb: Always non-stop (default to "maint set target-non-stop on") Pedro Alves
2025-05-29 16:02   ` Tom Tromey
2025-05-19 13:23 ` [PATCH v2 47/47] Mention Windows scheduler-locking and non-stop support in NEWS Pedro Alves
2025-05-19 14:07   ` Eli Zaretskii
2025-06-05 17:57 ` [PATCH v2 00/47] Windows non-stop mode Tom Tromey
2025-06-11 22:06   ` [PATCH] Improve attach on Windows (was: Re: [PATCH v2 00/47] Windows non-stop mode) Pedro Alves
2026-04-02 12:21     ` [PATCH] Improve attach on Windows Pedro Alves
2026-04-02 18:52       ` Tom Tromey
2025-06-11 23:51   ` [PATCH v2 00/47] Windows non-stop mode Pedro Alves
2025-06-12 19:23     ` Tom Tromey
2025-06-13 10:34       ` Pedro Alves
2025-06-13 14:23         ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250519132308.3553663-45-pedro@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox