[binutils-gdb] linux_nat.c: Mark new thread running even if momentarily pausing

[Pedro Alves <palves at sourceware dot org>]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2ee52aa4283145a0f9417986b2f3d7f91e61b1b0

commit 2ee52aa4283145a0f9417986b2f3d7f91e61b1b0
Author: Pedro Alves <palves@redhat.com>
Date:   Tue Mar 24 14:24:53 2015 +0000

    linux_nat.c: Mark new thread running even if momentarily pausing
    
    My all-stop-on-top-of-non-stop series manages to trip on a bug in the
    linux-nat.c backend while running the testsuite.  If a thread is
    discovered while threads are being momentarily paused (without the
    core's intervention), the thread ends up stuck in THREAD_STOPPED
    state, even though from the user's perspective, the thread is running
    even while it is paused.
    
    From inspection, in the current sources, this can happen if we call
    stop_and_resume_callback, though there's no way to test that with
    current Linux kernels.
    
    (While trying to come up with test to exercise this, I stumbled on:
      https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html
    
    ... which does include a non-trivial test, so I think I can still
    claim I come out net positive. :-) )
    
    Tested on x86_64 Fedora 20.
    
    gdb/ChangeLog:
    2015-04-01  Pedro Alves  <palves@redhat.com>
    
    	* linux-nat.c (linux_handle_extended_wait): Always call set_running.

Diff:
---
 gdb/ChangeLog   | 4 ++++
 gdb/linux-nat.c | 5 ++++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 621f4f5..838c685 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2015-04-01  Pedro Alves  <palves@redhat.com>
+
+	* linux-nat.c (linux_handle_extended_wait): Always call set_running.
+
 2015-04-01  Pierre-Marie de Rodat  <derodat@adacore.com>
 
 	* MAINTAINERS (Write After Approval): Add "Pierre-Marie de Rodat".
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 0376299..04707dc 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -2109,9 +2109,12 @@ linux_handle_extended_wait (struct lwp_info *lp, int status,
 	      add_thread (new_lp->ptid);
 	    }
 
+	  /* Even if we're stopping the thread for some reason
+	     internal to this module, from the user/frontend's
+	     perspective, this new thread is running.  */
+	  set_running (new_lp->ptid, 1);
 	  if (!stopping)
 	    {
-	      set_running (new_lp->ptid, 1);
 	      set_executing (new_lp->ptid, 1);
 	      /* thread_db_attach_lwp -> lin_lwp_attach_lwp forced
 		 resume_stop.  */