From: Pedro Alves <pedro@palves.net>
To: gdb-patches@sourceware.org
Cc: Eli Zaretskii <eliz@gnu.org>, Andrew Burgess <aburgess@redhat.com>
Subject: [FYI/pushed v4 20/25] Don't resume new threads if scheduler-locking is in effect
Date: Mon, 13 Nov 2023 15:04:22 +0000 [thread overview]
Message-ID: <20231113150427.477431-21-pedro@palves.net> (raw)
In-Reply-To: <20231113150427.477431-1-pedro@palves.net>
If scheduler-locking is in effect, e.g., with "set scheduler-locking
on", and you step over a function that spawns a new thread, the new
thread is allowed to run free, at least until some event is hit, at
which point, whether the new thread is re-resumed depends on a number
of seemingly random factors. E.g., if the target is all-stop, and the
parent thread hits a breakpoint, and GDB decides the breakpoint isn't
interesting to report to the user, then the parent thread is resumed,
but the new thread is left stopped.
I think that letting the new threads run with scheduler-locking
enabled is a defect. This commit fixes that, making use of the new
clone events on Linux, and of target_thread_events() on targets where
new threads have no connection to the thread that spawned them.
Testcase and documentation changes included.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce
---
gdb/NEWS | 7 ++
gdb/doc/gdb.texinfo | 4 +-
gdb/infrun.c | 41 +++++++++---
.../gdb.threads/schedlock-new-thread.c | 54 +++++++++++++++
.../gdb.threads/schedlock-new-thread.exp | 67 +++++++++++++++++++
5 files changed, 164 insertions(+), 9 deletions(-)
create mode 100644 gdb/testsuite/gdb.threads/schedlock-new-thread.c
create mode 100644 gdb/testsuite/gdb.threads/schedlock-new-thread.exp
diff --git a/gdb/NEWS b/gdb/NEWS
index d85a13b64fe..f2861b1ace1 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -392,6 +392,13 @@ show tui mouse-events
from the current process state. GDB will show this additional information
automatically, or through one of the memory-tag subcommands.
+* Scheduler-locking and new threads
+
+ When scheduler-locking is in effect, only the current thread may run
+ when the inferior is resumed. However, previously, new threads
+ created by the resumed thread would still be able to run free. Now,
+ they are held stopped.
+
* "info breakpoints" now displays enabled breakpoint locations of
disabled breakpoints as in the "y-" state. For example:
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 4cbaaa6804f..79b7431dd78 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -7123,7 +7123,9 @@ the following:
There is no locking and any thread may run at any time.
@item on
-Only the current thread may run when the inferior is resumed.
+Only the current thread may run when the inferior is resumed. New
+threads created by the resumed thread are held stopped at their entry
+point, before they execute any instruction.
@item step
Behaves like @code{on} when stepping, and @code{off} otherwise.
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 409c2249b13..943ea88538c 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -107,6 +107,8 @@ static bool start_step_over (void);
static bool step_over_info_valid_p (void);
+static bool schedlock_applies (struct thread_info *tp);
+
/* Asynchronous signal handler registered as event loop source for
when we have pending events ready to be passed to the core. */
static struct async_event_handler *infrun_async_inferior_event_token;
@@ -1961,7 +1963,13 @@ static void
update_thread_events_after_step_over (thread_info *event_thread,
const target_waitstatus &event_status)
{
- if (target_supports_set_thread_options (0))
+ if (schedlock_applies (event_thread))
+ {
+ /* If scheduler-locking applies, continue reporting
+ thread-created/thread-cloned events. */
+ return;
+ }
+ else if (target_supports_set_thread_options (0))
{
/* We can control per-thread options. Disable events for the
event thread, unless the thread is gone. */
@@ -2535,9 +2543,14 @@ do_target_resume (ptid_t resume_ptid, bool step, enum gdb_signal sig)
to start stopped. We need to release the displaced stepping
buffer if the stepped thread exits, so we also enable
thread-exit events.
+
+ - If scheduler-locking applies, threads that the current thread
+ spawns should remain halted. It's not strictly necessary to
+ enable thread-exit events in this case, but it doesn't hurt.
*/
if (step_over_info_valid_p ()
- || displaced_step_in_progress_thread (tp))
+ || displaced_step_in_progress_thread (tp)
+ || schedlock_applies (tp))
{
gdb_thread_options options
= GDB_THREAD_OPTION_CLONE | GDB_THREAD_OPTION_EXIT;
@@ -2546,6 +2559,13 @@ do_target_resume (ptid_t resume_ptid, bool step, enum gdb_signal sig)
else
target_thread_events (true);
}
+ else
+ {
+ if (target_supports_set_thread_options (0))
+ tp->set_thread_options (0);
+ else if (!displaced_step_in_progress_any_thread ())
+ target_thread_events (false);
+ }
/* If we're resuming more than one thread simultaneously, then any
thread other than the leader is being set to run free. Clear any
@@ -6295,16 +6315,21 @@ handle_inferior_event (struct execution_control_state *ecs)
parent->set_running (false);
/* If resuming the child, mark it running. */
- if (ecs->ws.kind () == TARGET_WAITKIND_THREAD_CLONED
- || (follow_child || (!detach_fork && (non_stop || sched_multi))))
+ if ((ecs->ws.kind () == TARGET_WAITKIND_THREAD_CLONED
+ && !schedlock_applies (ecs->event_thread))
+ || (ecs->ws.kind () != TARGET_WAITKIND_THREAD_CLONED
+ && (follow_child
+ || (!detach_fork && (non_stop || sched_multi)))))
child->set_running (true);
/* In non-stop mode, also resume the other branch. */
if ((ecs->ws.kind () == TARGET_WAITKIND_THREAD_CLONED
- && target_is_non_stop_p ())
- || (!detach_fork && (non_stop
- || (sched_multi
- && target_is_non_stop_p ()))))
+ && target_is_non_stop_p ()
+ && !schedlock_applies (ecs->event_thread))
+ || (ecs->ws.kind () != TARGET_WAITKIND_THREAD_CLONED
+ && (!detach_fork && (non_stop
+ || (sched_multi
+ && target_is_non_stop_p ())))))
{
if (follow_child)
switch_to_thread (parent);
diff --git a/gdb/testsuite/gdb.threads/schedlock-new-thread.c b/gdb/testsuite/gdb.threads/schedlock-new-thread.c
new file mode 100644
index 00000000000..4fe776906c6
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/schedlock-new-thread.c
@@ -0,0 +1,54 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2021-2023 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 void *
+thread_func (void *arg)
+{
+#if !SCHEDLOCK
+ while (1)
+ sleep (1);
+#endif
+
+ return NULL;
+}
+
+int
+main (void)
+{
+ pthread_t thread;
+ int ret;
+
+ ret = pthread_create (&thread, NULL, thread_func, NULL); /* set break 1 here */
+ assert (ret == 0);
+
+#if SCHEDLOCK
+ /* When testing with schedlock enabled, the new thread won't run, so
+ we can't join it, as that would hang forever. Instead, sleep for
+ a bit, enough that if the spawned thread is scheduled, it hits
+ the thread_func breakpoint before the main thread reaches the
+ "return 0" line below. */
+ sleep (3);
+#else
+ pthread_join (thread, NULL);
+#endif
+
+ return 0; /* set break 2 here */
+}
diff --git a/gdb/testsuite/gdb.threads/schedlock-new-thread.exp b/gdb/testsuite/gdb.threads/schedlock-new-thread.exp
new file mode 100644
index 00000000000..ecaeea58f82
--- /dev/null
+++ b/gdb/testsuite/gdb.threads/schedlock-new-thread.exp
@@ -0,0 +1,67 @@
+# Copyright 2021-2023 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 over a thread spawn with scheduler-locking on.
+
+standard_testfile .c
+
+foreach_with_prefix schedlock {off on} {
+ set sl [expr $schedlock == "on" ? 1 : 0]
+ if { [build_executable "failed to prepare" $testfile-$sl \
+ $srcfile \
+ [list debug pthreads additional_flags=-DSCHEDLOCK=$sl]] \
+ == -1 } {
+ return
+ }
+}
+
+proc test {non-stop schedlock} {
+ save_vars ::GDBFLAGS {
+ append ::GDBFLAGS " -ex \"set non-stop ${non-stop}\""
+ set sl [expr $schedlock == "on" ? 1 : 0]
+ clean_restart $::binfile-$sl
+ }
+
+ set linenum1 [gdb_get_line_number "set break 1 here"]
+
+ if { ![runto $::srcfile:$linenum1] } {
+ return
+ }
+
+ delete_breakpoints
+
+ set linenum2 [gdb_get_line_number "set break 2 here"]
+ gdb_breakpoint $linenum2
+
+ gdb_breakpoint "thread_func"
+
+ gdb_test_no_output "set scheduler-locking $schedlock"
+
+ if {$schedlock} {
+ gdb_test "continue" \
+ "return 0.*set break 2 here .*" \
+ "continue does not stop in new thread"
+ } else {
+ gdb_test "continue" \
+ "thread_func .*" \
+ "continue stops in new thread"
+ }
+}
+
+foreach_with_prefix non-stop {off on} {
+ foreach_with_prefix schedlock {off on} {
+ test ${non-stop} ${schedlock}
+ }
+}
--
2.34.1
next prev parent reply other threads:[~2023-11-13 15:05 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-13 15:04 [FYI/pushed v4 00/25] Step over thread clone and thread exit Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 01/25] Add "maint info linux-lwps" command Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 02/25] gdb/linux: Delete all other LWPs immediately on ptrace exec event Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 03/25] Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED Pedro Alves
2023-11-14 12:55 ` Guinevere Larsen
2023-11-14 13:26 ` Pedro Alves
2023-11-14 16:29 ` Guinevere Larsen
2023-11-14 16:44 ` Luis Machado
2023-11-14 13:28 ` Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 04/25] Support clone events in the remote protocol Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 05/25] Avoid duplicate QThreadEvents packets Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 06/25] Thread options & clone events (core + remote) Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 07/25] Thread options & clone events (native Linux) Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 08/25] Thread options & clone events (Linux GDBserver) Pedro Alves
2024-02-06 11:04 ` Luis Machado
2024-02-06 14:57 ` Tom Tromey
2024-02-06 15:12 ` Luis Machado
2024-02-07 8:59 ` Luis Machado
2024-02-07 15:43 ` Tom Tromey
2024-02-07 17:10 ` Simon Marchi
2024-02-07 18:05 ` Luis Machado
2024-02-07 18:18 ` Tom Tromey
2024-02-07 18:56 ` Pedro Alves
2024-02-07 20:11 ` Pedro Alves
2024-02-08 8:57 ` Luis Machado
2024-02-08 10:53 ` Pedro Alves
2024-02-08 11:47 ` Luis Machado
2024-02-08 14:58 ` Tom Tromey
2024-02-07 18:06 ` Tom Tromey
2023-11-13 15:04 ` [FYI/pushed v4 09/25] gdbserver: Hide and don't detach pending clone children Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 10/25] Remove gdb/19675 kfails (displaced stepping + clone) Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 11/25] all-stop/synchronous RSP support thread-exit events Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 12/25] gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNORE Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 13/25] Move deleting thread on TARGET_WAITKIND_THREAD_EXITED to core Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 14/25] Introduce GDB_THREAD_OPTION_EXIT thread option, fix step-over-thread-exit Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 15/25] Implement GDB_THREAD_OPTION_EXIT support for Linux GDBserver Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 16/25] Implement GDB_THREAD_OPTION_EXIT support for native Linux Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 17/25] gdb: clear step over information on thread exit (PR gdb/27338) Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 18/25] stop_all_threads: (re-)enable async before waiting for stops Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 19/25] gdbserver: Queue no-resumed event after thread exit Pedro Alves
2023-11-13 15:04 ` Pedro Alves [this message]
2023-11-13 15:04 ` [FYI/pushed v4 21/25] Report thread exit event for leader if reporting thread exit events Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 22/25] gdb/testsuite/lib/my-syscalls.S: Refactor new SYSCALL macro Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 23/25] Testcases for stepping over thread exit syscall (PR gdb/27338) Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 24/25] Document remote clone events, and QThreadOptions packet Pedro Alves
2023-11-13 15:04 ` [FYI/pushed v4 25/25] Cancel execution command on thread exit, when stepping, nexting, etc Pedro Alves
2023-11-13 19:28 ` [FYI/pushed v4 00/25] Step over thread clone and thread exit Tom de Vries
2023-11-14 10:51 ` Pedro Alves
2023-11-14 13:39 ` Tom de Vries
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=20231113150427.477431-21-pedro@palves.net \
--to=pedro@palves.net \
--cc=aburgess@redhat.com \
--cc=eliz@gnu.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).