From 856e7dd6986d26b251d91b7fcd10c08fb57dc73b Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Tue, 24 Mar 2015 17:50:31 +0000 Subject: Make "set scheduler-locking step" depend on user intention, only Currently, "set scheduler-locking step" is a bit odd. The manual documents it as being optimized for stepping, so that focus of debugging does not change unexpectedly, but then it says that sometimes other threads may run, and thus focus may indeed change unexpectedly... A user can then be excused to get confused and wonder why does GDB behave like this. I don't think a user should have to know about details of how "next" or whatever other run control command is implemented internally to understand when does the "scheduler-locking step" setting take effect. This patch completes a transition that the code has been moving towards for a while. It makes "set scheduler-locking step" hold threads depending on whether the _command_ the user entered was a stepping command [step/stepi/next/nexti], or not. Before, GDB could end up locking threads even on "continue" if for some reason run control decides a thread needs to be single stepped (e.g., for a software watchpoint). After, if a "continue" happens to need to single-step for some reason, we won't lock threads (unless when stepping over a breakpoint, naturally). And if a stepping command wants to continue a thread for bit, like when skipping a function to a step-resume breakpoint, we'll still lock threads, so focus of debugging doesn't change. In order to make this work, we need to record in the thread structure whether what set it running was a stepping command. (A follow up patch will remove the "step" parameters of 'proceed' and 'resume') FWIW, Fedora GDB, which defaults to "scheduler-locking step" (mainline defaults to "off") carries a different patch that goes in this direction as well. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2015-03-24 Pedro Alves * gdbthread.h (struct thread_control_state) : New field. * infcmd.c (step_once): Pass step=1 to clear_proceed_status. Set the thread's stepping_command field. * infrun.c (resume): Check the thread's stepping_command flag to determine which threads should be resumed. Rename 'entry_step' local to user_step. (clear_proceed_status_thread): Clear 'stepping_command'. (schedlock_applies): Change parameter type to struct thread_info pointer. Adjust. (find_thread_needs_step_over): Remove 'step' parameter. Adjust. (switch_back_to_stepped_thread): Adjust calls to 'schedlock_applies'. (_initialize_infrun): Adjust "set scheduler-locking step" help. gdb/testsuite/ChangeLog: 2015-03-24 Pedro Alves * gdb.threads/schedlock.exp (test_step): No longer expect that "set scheduler-locking step" with "next" over a function call runs threads unlocked. gdb/doc/ChangeLog: 2015-03-24 Pedro Alves * gdb.texinfo (test_step) : No longer mention that threads may sometimes run unlocked. --- gdb/gdbthread.h | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'gdb/gdbthread.h') diff --git a/gdb/gdbthread.h b/gdb/gdbthread.h index ce4f76f..bb15717 100644 --- a/gdb/gdbthread.h +++ b/gdb/gdbthread.h @@ -138,6 +138,11 @@ struct thread_control_state thread was resumed as a result of a command applied to some other thread (e.g., "next" with scheduler-locking off). */ struct interp *command_interp; + + /* Whether the command that started the thread was a stepping + command. This is used to decide whether "set scheduler-locking + step" behaves like "on" or "off". */ + int stepping_command; }; /* Inferior thread specific part of `struct infcall_suspend_state'. -- cgit v1.1