GDBserver: clean up 'cont_thread' handling

As no place in the backends check cont_thread anymore, we can stop
setting and clearing it in places that resume the target and wait for
events.  Instead simply clear it whenever a new GDB connects.

gdb/gdbserver/
2014-11-12  Pedro Alves  <palves@redhat.com>

	* server.c (cont_thread): Update comment.
	(start_inferior, attach_inferior): No longer clear cont_thread.
	(handle_v_cont): No longer set cont_thread.
	(captured_main): Clear cont_thread each time a GDB connects.

2 files changed, 9 insertions, 24 deletions

diff --git a/gdb/gdbserver/ChangeLog b/gdb/gdbserver/ChangeLog
index d162844..5a42642 100644
--- a/gdb/gdbserver/ChangeLog
+++ b/gdb/gdbserver/ChangeLog
@@ -1,5 +1,12 @@
 2014-11-12  Pedro Alves  <palves@redhat.com>
 
+	* server.c (cont_thread): Update comment.
+	(start_inferior, attach_inferior): No longer clear cont_thread.
+	(handle_v_cont): No longer set cont_thread.
+	(captured_main): Clear cont_thread each time a GDB connects.
+
+2014-11-12  Pedro Alves  <palves@redhat.com>
+
 	* linux-low.c (linux_wait_1): Don't force a wait for the Hc
 	thread, and don't resume all threads if the Hc thread has exited.
 
diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c
index 522d6f6..173a22e 100644
--- a/gdb/gdbserver/server.c
+++ b/gdb/gdbserver/server.c
@@ -41,11 +41,7 @@
    requirement, so `Hc pPID.TID' is pretty much undefined.  So
    CONT_THREAD can be null_ptid for no `Hc' thread, minus_one_ptid for
    resuming all threads of the process (again, `Hc' isn't used for
-   multi-process), or a specific thread ptid_t.
-
-   We also set this when handling a single-thread `vCont' resume, as
-   some places in the backends check it to know when (and for which
-   thread) single-thread scheduler-locking is in effect.  */
+   multi-process), or a specific thread ptid_t.  */
 ptid_t cont_thread;
 
 /* The thread set with an `Hg' packet.  */
@@ -225,10 +221,6 @@ start_inferior (char **argv)
   signal (SIGTTIN, SIG_DFL);
 #endif
 
-  /* Clear this so the backend doesn't get confused, thinking
-     CONT_THREAD died, and it needs to resume all threads.  */
-  cont_thread = null_ptid;
-
   signal_pid = create_inferior (new_argv[0], new_argv);
 
   /* FIXME: we don't actually know at this point that the create
@@ -307,10 +299,6 @@ attach_inferior (int pid)
      whichever we were told to attach to.  */
   signal_pid = pid;
 
-  /* Clear this so the backend doesn't get confused, thinking
-     CONT_THREAD died, and it needs to resume all threads.  */
-  cont_thread = null_ptid;
-
   if (!non_stop)
     {
       last_ptid = mywait (pid_to_ptid (pid), &last_status, 0, 0);
@@ -2305,17 +2293,6 @@ handle_v_cont (char *own_buf)
   if (i < n)
     resume_info[i] = default_action;
 
-  /* `cont_thread' is still used in occasional places in the backend,
-     to implement single-thread scheduler-locking.  Doesn't make sense
-     to set it if we see a stop request, or a wildcard action (one
-     with '-1' (all threads), or 'pPID.-1' (all threads of PID)).  */
-  if (n == 1
-      && !(ptid_equal (resume_info[0].thread, minus_one_ptid)
-	   || ptid_get_lwp (resume_info[0].thread) == -1)
-      && resume_info[0].kind != resume_stop)
-    cont_thread = resume_info[0].thread;
-  else
-    cont_thread = minus_one_ptid;
   set_desired_thread (0);
 
   resume (resume_info, n);
@@ -3267,6 +3244,7 @@ captured_main (int argc, char *argv[])
       multi_process = 0;
       /* Be sure we're out of tfind mode.  */
       current_traceframe = -1;
+      cont_thread = null_ptid;
 
       remote_open (port);