From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Subject: [PATCH v2 04/47] infrun: Split currently_stepping, fix sw watchpoints issue
Date: Mon, 19 May 2025 14:22:25 +0100 [thread overview]
Message-ID: <20250519132308.3553663-5-pedro@palves.net> (raw)
In-Reply-To: <20250519132308.3553663-1-pedro@palves.net>
The gdb.base/watchpoint.exp on Windows with non-stop support added
(later in the series) exposed an issue with the currently_stepping
logic when tested with software watchpoints.
The issue only happens when:
- You have multiple threads. gdb.base/watchpoint.exp exposed it on
Windows because there the OS always spawns a few extra threads.
- Displaced stepping is not available. The Windows non-stop work
does not implement displaced stepping yet. That is left as an
optimization for later.
- The target backend is working in non-stop mode.
I've written a new test that exposes the issue on GNU/Linux as well
(on hardware single-step targets, like x86-64). There, we see:
continue
Continuing.
../../src/gdb/infrun.c:2918: internal-error: resume_1: Assertion `!(thread_has_single_step_breakpoints_set (tp) && step)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp: target-non-stop=on: displaced-stepping=off: continue until exit (GDB internal error)
Currently, software watchpoints are implemented by forcing
single-stepping. That is done by currently_stepping returning true
when we have a software watchpoint. proceed calls resume, which calls
resume_1, which then ends up always requesting a single-step resume,
even if the higher layers wanted a continue.
Now, if you set a software watchpoint, and then continue the program,
and there's a breakpoint at the current PC, GDB needs to step over
that breakpoint first. If displaced stepping is not available, then
GDB temporarily pauses all threads, removes the breakpoint,
single-steps the thread that needs to move past the breakpoint, and
then finally, reinserts the breakpoint, and restarts all threads
again. That last restarting step happens in the restart_threads
infrun function.
restart_threads iterates over all threads trying to restart them one
by one. There, we have:
if (currently_stepping (tp))
{
infrun_debug_printf ("restart threads: [%s] was stepping",
tp->ptid.to_string ().c_str ());
but, what if TP is actually a new thread that hasn't yet ever set
stepping? currently_stepping still returns true, due to the software
watchpoint, and we end up in keep_going_stepped_thread, here:
if (tp->stop_pc () != tp->prev_pc)
{
ptid_t resume_ptid;
infrun_debug_printf ("expected thread advanced also (%s -> %s)",
paddress (current_inferior ()->arch (), tp->prev_pc),
paddress (current_inferior ()->arch (),
tp->stop_pc ()));
... because prev_pc was stale at that point (we had no reason to
update it earlier). E.g. on Windows we see something like:
[infrun] restart_threads: start: event_thread=1867996.1867996.0, inf=-1
[infrun] restart_threads: restart threads: [1867996.1867996.0] is event thread
[infrun] restart_threads: restart threads: [1867996.1868003.0] was stepping
[infrun] keep_going_stepped_thread: resuming previously stepped thread
[infrun] keep_going_stepped_thread: expected thread advanced also (0 -> 0x7ffff7ce57f8)
[infrun] clear_step_over_info: clearing step over info
[infrun] do_target_resume: resume_ptid=1867996.1868003.0, step=0, sig=GDB_SIGNAL_0
On GNU/Linux, we may see:
[infrun] keep_going_stepped_thread: expected thread advanced also (0x7ffff7d2683d -> 0x7ffff7ce57f8)
there prev_pc might have been updated on an earlier proceed call,
which makes the issue harder to see, but it is stale too here.
That means we insert a single-step breakpoint at the current PC, and
continue the thread, with target_resume directly, asking for a normal
continue.
Eventually, something causes a user-visible stop. For example, the
software watchpoint triggers. That makes GDB stop all threads.
Now, if the user re-resumes the program, say, with "continue", we fail
this assertion in resume_1 coming from proceed:
/* If STEP is set, it's a request to use hardware stepping
facilities. But in that case, we should never
use singlestep breakpoint. */
gdb_assert (!(thread_has_single_step_breakpoints_set (tp) && step));
"step" is true because currently_stepping returns true since we have a
software watchpoint. And the thread has a single-step breakpoint
installed from earlier, because of that code mentioned above, in
keep_going_stepped_thread reached from restart_threads.
This patch fixes the root cause -- the currently_stepping call in
restart_threads returned true for a thread that has never set stepping
in the first place. This is because currently_stepping really serves
two purposes currently:
#1 - for a thread that we are about to resume, should we set it
stepping?
#2 - for a thread that just stopped, was it stepping before?
The fix is thus to decouple those two aspects:
- for #1, we simply rename currently_stepping to should_step.
- for #2, we record whether the thread was stepping before in a new
currently_stepping flag in thread_info.
As mentioned, there's a new testcase included. I tested this on
x86-64 GNU/Linux, native and gdbserver, and on Windows x64 with the
non-stop series. The assertion triggers on all of those with the fix,
and is fixed by this patch on all of those, too.
Change-Id: I7b07bc62e8570333d2e4856d2e55ae6e58f8260c
---
gdb/gdbthread.h | 4 +
gdb/infrun.c | 28 +++---
.../sw-watchpoint-step-over-bp-with-threads.c | 64 +++++++++++++
...w-watchpoint-step-over-bp-with-threads.exp | 91 +++++++++++++++++++
4 files changed, 173 insertions(+), 14 deletions(-)
create mode 100644 gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.c
create mode 100644 gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h
index c561e9a7b64..a8fd967c702 100644
--- a/gdb/gdbthread.h
+++ b/gdb/gdbthread.h
@@ -152,6 +152,10 @@ struct thread_control_state
the finished single step. */
int trap_expected = 0;
+ /* True if the thread TP is in the middle of (software or hardware)
+ single-stepping. */
+ bool currently_stepping = false;
+
/* Nonzero if the thread is being proceeded for a "finish" command
or a similar situation when return value should be printed. */
int proceed_to_finish = 0;
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 119bd151034..9f625a7bd44 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -87,7 +87,7 @@ static void sig_print_header (void);
static void follow_inferior_reset_breakpoints (void);
-static bool currently_stepping (struct thread_info *tp);
+static bool should_step (thread_info *tp);
static void insert_hp_step_resume_breakpoint_at_frame (const frame_info_ptr &);
@@ -2656,7 +2656,7 @@ resume_1 (enum gdb_signal sig)
"status %s (currently_stepping=%d).",
tp->ptid.to_string ().c_str (),
tp->pending_waitstatus ().to_string ().c_str (),
- currently_stepping (tp));
+ tp->control.currently_stepping);
tp->inf->process_target ()->threads_executing = true;
tp->set_resumed (true);
@@ -2685,7 +2685,7 @@ resume_1 (enum gdb_signal sig)
tp->stepped_breakpoint = 0;
/* Depends on stepped_breakpoint. */
- step = currently_stepping (tp);
+ step = tp->control.currently_stepping = should_step (tp);
if (current_inferior ()->thread_waiting_for_vfork_done != nullptr)
{
@@ -3060,7 +3060,7 @@ clear_proceed_status_thread (struct thread_info *tp)
("thread %s has pending wait status %s (currently_stepping=%d).",
tp->ptid.to_string ().c_str (),
tp->pending_waitstatus ().to_string ().c_str (),
- currently_stepping (tp));
+ tp->control.currently_stepping);
}
}
@@ -5041,7 +5041,7 @@ adjust_pc_after_break (struct thread_info *thread,
we also need to back up to the breakpoint address. */
if (thread_has_single_step_breakpoints_set (thread)
- || !currently_stepping (thread)
+ || !thread->control.currently_stepping
|| (thread->stepped_breakpoint
&& thread->prev_pc == breakpoint_pc))
regcache_write_pc (regcache, breakpoint_pc);
@@ -5368,7 +5368,7 @@ save_waitstatus (struct thread_info *tp, const target_waitstatus &ws)
&& software_breakpoint_inserted_here_p (aspace, pc))
tp->set_stop_reason (TARGET_STOPPED_BY_SW_BREAKPOINT);
else if (!thread_has_single_step_breakpoints_set (tp)
- && currently_stepping (tp))
+ && tp->control.currently_stepping)
tp->set_stop_reason (TARGET_STOPPED_BY_SINGLE_STEP);
}
}
@@ -5563,7 +5563,7 @@ handle_one (const wait_one_event &event)
paddress (current_inferior ()->arch (),
t->stop_pc ()),
t->ptid.to_string ().c_str (),
- currently_stepping (t));
+ t->control.currently_stepping);
}
}
@@ -6668,7 +6668,7 @@ restart_threads (struct thread_info *event_thread, inferior *inf)
tp->ptid.to_string ().c_str ());
}
- if (currently_stepping (tp))
+ if (tp->control.currently_stepping)
{
infrun_debug_printf ("restart threads: [%s] was stepping",
tp->ptid.to_string ().c_str ());
@@ -6795,7 +6795,7 @@ finish_step_over (struct execution_control_state *ecs)
paddress (current_inferior ()->arch (),
tp->stop_pc ()),
tp->ptid.to_string ().c_str (),
- currently_stepping (tp));
+ tp->control.currently_stepping);
/* This in-line step-over finished; clear this so we won't
start a new one. This is what handle_signal_stop would
@@ -7204,7 +7204,7 @@ handle_signal_stop (struct execution_control_state *ecs)
/* If not, perhaps stepping/nexting can. */
if (random_signal)
random_signal = !(ecs->event_thread->stop_signal () == GDB_SIGNAL_TRAP
- && currently_stepping (ecs->event_thread));
+ && ecs->event_thread->control.currently_stepping);
/* Perhaps the thread hit a single-step breakpoint of _another_
thread. Single-step breakpoints are transparent to the
@@ -8632,12 +8632,12 @@ keep_going_stepped_thread (struct thread_info *tp)
return true;
}
-/* Is thread TP in the middle of (software or hardware)
- single-stepping? (Note the result of this function must never be
- passed directly as target_resume's STEP parameter.) */
+/* Should thread TP be stepped (software or hardware)? (Note the
+ result of this function must never be passed directly as
+ target_resume's STEP parameter.) */
static bool
-currently_stepping (struct thread_info *tp)
+should_step (thread_info *tp)
{
return ((tp->control.step_range_end
&& tp->control.step_resume_breakpoint == nullptr)
diff --git a/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.c b/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.c
new file mode 100644
index 00000000000..7f014036c9b
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.c
@@ -0,0 +1,64 @@
+/* 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 *
+thread_func (void *arg)
+{
+ pthread_barrier_wait (&threads_started_barrier);
+
+ while (1)
+ sleep (1);
+
+ return NULL;
+}
+
+static void
+dummy ()
+{
+}
+
+static unsigned watched_global = 0;
+
+int
+main (void)
+{
+ pthread_t thread;
+ int ret;
+
+ alarm (30);
+
+ pthread_barrier_init (&threads_started_barrier, NULL, 2);
+
+ ret = pthread_create (&thread, NULL, thread_func, NULL);
+ assert (ret == 0);
+
+ /* Make sure all threads are scheduled before hitting the
+ breakpoint. */
+ pthread_barrier_wait (&threads_started_barrier);
+
+ ++watched_global; /* break here start */
+
+ dummy (); /* just so there's extra code here */
+
+ return 0; /* break here end */
+}
diff --git a/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp b/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
new file mode 100644
index 00000000000..b45db57e80f
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
@@ -0,0 +1,91 @@
+# 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/>.
+
+# Test continuing with a software watchpoint installed, when there are
+# multiple threads, and previously we stepped over a breakpoint.
+#
+# This is a regression test for a GDB bug where stepping over a
+# breakpoint in-line made GDB insert a software single-step breakpoint
+# in some threads by mistake, which later would cause an assertion to
+# fail.
+#
+# The issue only triggered when:
+#
+# - The program has multiple threads.
+# - The target backend is working in non-stop mode.
+# - Displaced stepping is not available.
+# - The target supports hardware single-step.
+#
+# However, we exercise more combinations for completeness.
+
+standard_testfile .c
+
+if { [build_executable "failed to prepare" $testfile $srcfile \
+ {debug pthreads}] \
+ == -1 } {
+ return
+}
+
+proc test {target-non-stop displaced-stepping} {
+
+ save_vars ::GDBFLAGS {
+ append ::GDBFLAGS " -ex \"maintenance set target-non-stop ${target-non-stop}\""
+ append ::GDBFLAGS " -ex \"set displaced ${displaced-stepping}\""
+ clean_restart $::binfile
+ }
+
+ if ![runto_main] {
+ return
+ }
+
+ # Run to a breakpoint, and leave it installed, so that GDB needs
+ # to step over it before continuing.
+ gdb_breakpoint [gdb_get_line_number "break here start"]
+ gdb_continue_to_breakpoint "started"
+
+ # GDB should know about at least two threads by now.
+ gdb_test "p \$_inferior_thread_count >= 2" " = 1"
+
+ # Set a software watchpoint. This makes GDB single-step all
+ # instructions when we next continue.
+ gdb_test_no_output "set can-use-hw-watchpoints 0"
+ gdb_test "watch watched_global" "Watchpoint $::decimal: watched_global"
+
+ # Continue with the software watchpoint in place. In the original
+ # bug, with displaced stepping disabled, this would make GDB
+ # incorrectly install a software single-step breakpoint on threads
+ # other than the main one.
+ gdb_test_multiple "cont" "continue to watchpoint" {
+ -re -wrap "Continuing.*Watchpoint.*watched_global.*Old value = 0.*New value = 1.*" {
+ pass $gdb_test_name
+ }
+ }
+
+ # The final continue, with the software watchpoint set, so that
+ # GDB single-steps all threads (if the target is non-stop). With
+ # the buggy GDB, the non-main thread had a software single-step
+ # breakpoint set, and on hardware single-step targets, GDB would
+ # fail an assertion that checks that we never ask the target to
+ # hardware single-step a thread when we have a software
+ # single-step breakpoint set for that thread.
+ gdb_breakpoint [gdb_get_line_number "break here end"]
+ gdb_continue_to_breakpoint "end"
+}
+
+foreach_with_prefix target-non-stop {auto on off} {
+ foreach_with_prefix displaced-stepping {auto on off} {
+ test ${target-non-stop} ${displaced-stepping}
+ }
+}
--
2.49.0
next prev parent reply other threads:[~2025-05-19 13:24 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 ` Pedro Alves [this message]
2026-04-02 13:33 ` [PATCH v2 04/47] infrun: Split currently_stepping, fix sw watchpoints issue 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 ` [PATCH v2 44/47] Add gdb.threads/leader-exit-schedlock.exp Pedro Alves
2025-05-29 16:09 ` 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-5-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