Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: pedro@codesourcery.com (Pedro Alves)
Cc: gdb-patches@sourceware.org
Subject: Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread).
Date: Mon, 16 Aug 2010 18:41:00 -0000	[thread overview]
Message-ID: <201008161840.o7GIel4W024223@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <201008161930.20550.pedro@codesourcery.com> from "Pedro Alves" at Aug 16, 2010 07:30:20 PM

Pedro Alves wrote:

> Replacing the "next" by a "continue" should work.  I've looked over the
> original description of the problem this is covering, and, that
> would still exercise the problem (which is gdb trying to step
> the other (main) thread with inferior_ptid still pointing at
> the thread that was being "next"ed, and in the process failing
> to remove breakpoints from memory because inferior_ptid pointed
> at an inferior thread.

But isn't the code your patch changes under an if that's only true
if another thread is currently being stepped or nexted?  If we just
do "continue" here, that's no longer the case, and the code wouldn't
be exercised at all ...

@@ -3483,7 +3486,7 @@ infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME (
   if (!non_stop)
     {
       struct thread_info *tp;
-      tp = iterate_over_threads (currently_stepping_callback,
+      tp = iterate_over_threads (currently_stepping_or_nexting_callback,
 				 ecs->event_thread);
       if (tp)
 	{
@@ -3498,6 +3501,21 @@ 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 (is_exited (tp->ptid)
+	      || !target_thread_alive (tp->ptid))
+	    {
+	      if (debug_infrun)
+		fprintf_unfiltered (gdb_stdlog, "\
+infrun: not switching back to stepped thread, it has vanished\n");
+
+	      delete_thread (tp->ptid);
+	      keep_going (ecs);
+	      return;
+	    }
+
 	  /* Otherwise, we no longer expect a trap in the current thread.
 	     Clear the trap_expected flag before switching back -- this is
 	     what keep_going would do as well, if we called it.  */


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


  parent reply	other threads:[~2010-08-16 18:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27 22:00 Pedro Alves
2009-05-28 11:12 ` Ulrich Weigand
2009-05-28 17:20   ` Pedro Alves
2009-06-09 19:58 ` Joel Brobecker
2009-06-10 16:20   ` Pedro Alves
2009-06-10 16:37     ` Joel Brobecker
2010-08-16 17:38 ` Ulrich Weigand
2010-08-16 18:30   ` Pedro Alves
2010-08-16 18:32     ` Pedro Alves
2010-08-16 18:41     ` Ulrich Weigand [this message]
2010-08-16 18:53       ` Pedro Alves
2010-08-16 19:01         ` Ulrich Weigand
2010-09-08 18:18         ` [commit] " Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201008161840.o7GIel4W024223@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox