yet another clone handling fix

[Pedro Alves]

Something else putting the core under control of stopping
all threads revealed.  We'd end up with new threads stuck stopped,
because I missed that lin_lwp_attach_lwp forces resume_kind
to resume_stop.  I may revisit that later.

Tested on x86_64-linux and applied.

-- 
Pedro Alves

2011-10-24  Pedro Alves  <pedro@codesourcery.com>

	gdb/
	* linux-nat.c (linux_handle_extended_wait): When handling a clone
	event, in non-stop, if not stopping, make sure the new lwp has
	last_resume_kind set to resume_continue.  Assert that when we're
	resuming the new lwp, its last_resume_kind is resume_continue.

---
 gdb/linux-nat.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: src/gdb/linux-nat.c
===================================================================
--- src.orig/gdb/linux-nat.c	2011-10-24 14:53:45.730715043 +0100
+++ src/gdb/linux-nat.c	2011-10-24 15:23:01.200715304 +0100
@@ -2289,6 +2289,9 @@ linux_handle_extended_wait (struct lwp_i
 		{
 		  set_running (new_lp->ptid, 1);
 		  set_executing (new_lp->ptid, 1);
+		  /* thread_db_attach_lwp -> lin_lwp_attach_lwp forced
+		     resume_stop.  */
+		  new_lp->last_resume_kind = resume_continue;
 		}
 	    }
 
@@ -2316,6 +2319,7 @@ linux_handle_extended_wait (struct lwp_i
 
 	      if (status == 0)
 		{
+		  gdb_assert (new_lp->last_resume_kind == resume_continue);
 		  if (debug_linux_nat)
 		    fprintf_unfiltered (gdb_stdlog,
 					"LHEW: resuming new LWP %ld\n",