Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: generic_prepare_to_proceed vs. Ctrl-C
Date: Tue, 22 May 2001 15:24:00 -0000	[thread overview]
Message-ID: <3B0AE715.17823A37@redhat.com> (raw)

David S's recently added generic_prepare_to_proceed() only takes account of
stopping at a breakpoint and switching threads. It does not deal with
stopping due to a Ctrl-C and switching threads. The below patch fixes this.

Okay to check in?

2001-05-22  Jonathan Larmour  <jlarmour@redhat.com>

	* arch-utils.c (generic_prepare_to_proceed): Allow for having
	stopped due to a Ctrl-C as well as breakpoints.

Jifl

Index: arch-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.c,v
retrieving revision 1.27
diff -u -5 -p -r1.27 arch-utils.c
--- arch-utils.c	2001/05/10 18:36:26	1.27
+++ arch-utils.c	2001/05/22 22:19:29
@@ -256,26 +256,26 @@ generic_prepare_to_proceed (int select_i
   struct target_waitstatus wait_status;
 
   /* Get the last target status returned by target_wait().  */
   get_last_target_status (&wait_ptid, &wait_status);
 
-  /* Make sure we were stopped at a breakpoint.  */
+  /* Make sure we were stopped either at a breakpoint, or because
+     of a Ctrl-C.  */
   if (wait_status.kind != TARGET_WAITKIND_STOPPED
-      || wait_status.value.sig != TARGET_SIGNAL_TRAP)
+      || (wait_status.value.sig != TARGET_SIGNAL_TRAP &&
+          wait_status.value.sig != TARGET_SIGNAL_INT))
     {
       return 0;
     }
 
   if (!ptid_equal (wait_ptid, minus_one_ptid)
       && !ptid_equal (inferior_ptid, wait_ptid))
     {
       /* Switched over from WAIT_PID.  */
       CORE_ADDR wait_pc = read_pc_pid (wait_ptid);
 
-      /* Avoid switching where it wouldn't do any good, i.e. if both
-         threads are at the same breakpoint.  */
-      if (wait_pc != read_pc () && breakpoint_here_p (wait_pc))
+      if (wait_pc != read_pc ())
 	{
 	  if (select_it)
 	    {
 	      /* User hasn't deleted the breakpoint.  Switch back to
 		 WAIT_PID and return non-zero.  */
@@ -286,12 +286,15 @@ generic_prepare_to_proceed (int select_i
 	      flush_cached_frames ();
 	      registers_changed ();
 	      stop_pc = wait_pc;
 	      select_frame (get_current_frame (), 0);
 	    }
-
-	  return 1;
+          /* Step over the breakpoint if there is one here. */
+          if (breakpoint_here_p (wait_pc))
+            {
+	      return 1;
+            }
 	}
     }
   return 0;
   
 }

-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine


             reply	other threads:[~2001-05-22 15:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-22 15:24 Jonathan Larmour [this message]
2001-05-22 16:29 ` Michael Snyder
2001-05-23  8:47 ` David Smith
2001-05-23 10:26   ` Jonathan Larmour
2001-06-06  9:07     ` Andrew Cagney

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=3B0AE715.17823A37@redhat.com \
    --to=jlarmour@redhat.com \
    --cc=gdb-patches@sources.redhat.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