This is the mail archive of the
mailing list for the GDB project.
[PATCH 0/4] Make "set scheduler-locking step" depend on user intention, only
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 11 Mar 2015 14:39:54 +0000
- Subject: [PATCH 0/4] Make "set scheduler-locking step" depend on user intention, only
- Authentication-results: sourceware.org; auth=none
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.
Thus this series 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. More details in patch #3.
The rest of the series is related groundwork and cleaning up.
Tested on x86_64 Fedora 20, native and gdbserver.
Pedro Alves (4):
No longer handle negative 'step' in 'proceed'
Make step_start_function be per thread
Make "set scheduler-locking step" depend on user intention, only
Remove 'step' parameters from 'proceed' and 'resume'
gdb/breakpoint.c | 2 +-
gdb/doc/gdb.texinfo | 5 +-
gdb/gdbthread.h | 8 ++
gdb/infcall.c | 2 +-
gdb/infcmd.c | 38 +++++----
gdb/infrun.c | 139 ++++++++++++++++----------------
gdb/infrun.h | 4 +-
gdb/mi/mi-main.c | 2 +-
gdb/testsuite/gdb.threads/schedlock.exp | 11 ++-
gdb/windows-nat.c | 2 +-
10 files changed, 114 insertions(+), 99 deletions(-)