[PATCH 0/4] Make "set scheduler-locking step" depend on user intention, only

[Pedro Alves <palves@redhat.com>]

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(-)

-- 
1.9.3