From 7ac958f267898ba87ae67ea04f94a3fda24567dc Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 30 Nov 2021 19:52:11 +0000 Subject: Don't resume new threads if scheduler-locking is in effect 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 Reviewed-By: Andrew Burgess Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce --- gdb/doc/gdb.texinfo | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'gdb/doc') diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 4cbaaa6..79b7431 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. -- cgit v1.1