Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread).

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 09 June 2009 20:58:07, Joel Brobecker wrote:

> Coming late on this discussion:
> 
> > +	  /* If the stepping thread exited, then don't try reverting
> > +	     back to it, just keep going.  We need to query the target
> > +	     in case it doesn't support thread exit events.  */
> 
> I'm just wondering if it would make sense to explain why you need to do
> that in the comment, or perhaps just explain what would happen if you
> didn't. There is such a nice description in the body of your email, and
> I'm thinking it's worth having a short summary in the code.
> 
> WDYT?
> 

Sure!

> (yes, I know, I'm a comments freak)

Something like this?  Or were you thinking on some different
aspect of the issue?  Let me know and I'll cook something
extra.

2009-06-10  Pedro Alves  <pedro@codesourcery.com>

	* infrun.c (handle_inferior_event): Update comment around trying
	to revert back to a stepping thread that has exited.

---
 gdb/infrun.c |   22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c	2009-06-10 16:48:24.000000000 +0100
+++ src/gdb/infrun.c	2009-06-10 17:18:20.000000000 +0100
@@ -3496,9 +3496,25 @@ infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME (
 	      return;
 	    }
 
-	  /* If the stepping thread exited, then don't try reverting
-	     back to it, just keep going.  We need to query the target
-	     in case it doesn't support thread exit events.  */
+	  /* If the stepping thread exited, then don't try to switch
+	     back and resume it, which could fail in several different
+	     ways depending on the target.  Instead, just keep going.
+
+	     We can find a stepping dead thread in the thread list in
+	     two cases:
+
+	     - The target supports thread exit events, and when the
+	     target tries to delete the thread from the thread list,
+	     inferior_ptid pointed at the exiting thread.  In such
+	     case, calling delete_thread does not really remove the
+	     thread from the list; instead, the thread is left listed,
+	     with 'exited' state.
+
+	     - The target's debug interface does not support thread
+	     exit events, and so we have no idea whatsoever if the
+	     previously stepping thread is still alive.  For that
+	     reason, we need to synchronously query the target
+	     now.  */
 	  if (is_exited (tp->ptid)
 	      || !target_thread_alive (tp->ptid))
 	    {