infrun: scheduler-locking replay

Record targets behave as if scheduler-locking were on in replay mode.  Add a
new scheduler-locking option "replay" to make this implicit behaviour explicit.
It behaves like "on" in replay mode and like "off" in record mode.

By making the current behaviour a scheduler-locking option, we allow the user
to change it.  Since it is the current behaviour, this new option is also
the new default.

One caveat is that when resuming a thread that is at the end of its execution
history, record btrace implicitly stops replaying other threads and resumes
the entire process.  This is a convenience feature to not require the user
to explicitly move all other threads to the end of their execution histories
before being able to resume the process.

We mimick this behaviour with scheduler-locking replay and move it from
record-btrace into infrun.  With all-stop on top of non-stop, we can't do
this in record-btrace anymore.

Record full does not really support multi-threading and is therefore not
impacted.  If it were extended to support multi-threading, it would 'benefit'
from this change.  The good thing is that all record targets will behave the
same with respect to scheduler-locking.

I put the code for this into clear_proceed_status.  It also sends the
about_to_proceed notification.

gdb/
	* NEWS: Announce new scheduler-locking mode.
	* infrun.c (schedlock_replay): New.
	(scheduler_enums): Add schedlock_replay.
	(scheduler_mode): Change default to schedlock_replay.
	(user_visible_resume_ptid): Handle schedlock_replay.
	(clear_proceed_status_thread): Stop replaying if resumed thread is
	not replaying.
	(schedlock_applies): Handle schedlock_replay.
	(_initialize_infrun): Document new scheduler-locking mode.
	* record-btrace.c (record_btrace_resume): Remove code to stop other
	threads when not replaying the resumed thread.

doc/
	* gdb.texinfo (All-Stop Mode): Describe new scheduler-locking mode.

2 files changed, 18 insertions, 11 deletions

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index 1e16e92..9164b89 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,7 @@
+2015-09-18  Markus Metzger  <markus.t.metzger@intel.com>
+
+	* gdb.texinfo (All-Stop Mode): Describe new scheduler-locking mode.
+
 2015-09-15  Pedro Alves  <palves@redhat.com>
 
 	PR remote/18965
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 4ecdb8f..0687039 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -5836,17 +5836,20 @@ locking the OS scheduler to allow only a single thread to run.
 @item set scheduler-locking @var{mode}
 @cindex scheduler locking mode
 @cindex lock scheduler
-Set the scheduler locking mode.  If it is @code{off}, then there is no
-locking and any thread may run at any time.  If @code{on}, then only the
-current thread may run when the inferior is resumed.  The @code{step}
-mode optimizes for single-stepping; it prevents other threads 
-from preempting the current thread while you are stepping, so that 
-the focus of debugging does not change unexpectedly.
-Other threads never get a chance to run when you step, and they are
-completely free to run when you use commands
-like @samp{continue}, @samp{until}, or @samp{finish}.  However, unless another
-thread hits a breakpoint during its timeslice, @value{GDBN} does not change
-the current thread away from the thread that you are debugging.
+Set the scheduler locking mode.  It applies to normal execution,
+record mode, and replay mode.  If it is @code{off}, then there is no
+locking and any thread may run at any time.  If @code{on}, then only
+the current thread may run when the inferior is resumed.  The
+@code{step} mode optimizes for single-stepping; it prevents other
+threads from preempting the current thread while you are stepping, so
+that the focus of debugging does not change unexpectedly.  Other
+threads never get a chance to run when you step, and they are
+completely free to run when you use commands like @samp{continue},
+@samp{until}, or @samp{finish}.  However, unless another thread hits a
+breakpoint during its timeslice, @value{GDBN} does not change the
+current thread away from the thread that you are debugging.  The
+@code{replay} mode behaves like @code{off} in record mode and like
+@code{on} in replay mode.
 
 @item show scheduler-locking
 Display the current scheduler locking mode.