This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread).
- From: Pedro Alves <pedro at codesourcery dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 10 Jun 2009 17:21:32 +0100
- Subject: Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread).
- References: <200905272300.28249.pedro@codesourcery.com> <20090609195807.GA25703@adacore.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))
{