Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA] Don't ignore consecutive breakpoints.
Date: Fri, 23 Nov 2007 20:10:00 -0000	[thread overview]
Message-ID: <200711232310.17854.vladimir@codesourcery.com> (raw)


Suppose we have two breakpoints at two consecutive
addresses, and we do "step" while stopped on the
first breakpoint. GDB testsuite has a test (consecutive.exp)
that the second breakpoint will be hit a reported, and the
test passes, but the code directly contradicts, saying:

      /* Don't even think about breakpoints if just proceeded over a
         breakpoint.  */
      if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
	{
          if (debug_infrun)
	    fprintf_unfiltered (gdb_stdlog, "infrun: trap expected\n");
	  bpstat_clear (&stop_bpstat);
	}

what's happening is that we indeed ignore the breakpoint, and try
to step further. However ecs->another_trap is not set, so we step
with breakpoints inserted, and immediately hit the now-inserted
breakpoint. Therefore, I propose to remove that code.

On x86, the below patch causes a single test outcome change:

-KFAIL: gdb.base/watchpoint.exp: next after watch x (PRMS: gdb/38)
+PASS: gdb.base/watchpoint.exp: next after watch x

The test is for a breakpoint set on a line that also triggers a
watchpoint. The outcome changed because we now do check breakpoints
after stepping over breakpoint. The target does not have any
watchpoint stop address, so we read watched value, and find that
in indeed has changed.

OK?

- Volodya

	* infrun.c (handle_inferior_event): Don't
	ignore beakpoints if trap_expected is set.
---
 gdb/infrun.c |   23 ++++++-----------------
 1 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 85d889a..feff6aa 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -1983,23 +1983,12 @@ handle_inferior_event (struct execution_control_state *ecs)
 	  return;
 	}
 
-      /* Don't even think about breakpoints if just proceeded over a
-         breakpoint.  */
-      if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
-	{
-          if (debug_infrun)
-	    fprintf_unfiltered (gdb_stdlog, "infrun: trap expected\n");
-	  bpstat_clear (&stop_bpstat);
-	}
-      else
-	{
-	  /* See if there is a breakpoint at the current PC.  */
-	  stop_bpstat = bpstat_stop_status (stop_pc, ecs->ptid);
-
-	  /* Following in case break condition called a
-	     function.  */
-	  stop_print_frame = 1;
-	}
+      /* See if there is a breakpoint at the current PC.  */
+      stop_bpstat = bpstat_stop_status (stop_pc, ecs->ptid);
+      
+      /* Following in case break condition called a
+	 function.  */
+      stop_print_frame = 1;
 
       /* NOTE: cagney/2003-03-29: These two checks for a random signal
          at one stage in the past included checks for an inferior
-- 
1.5.3.5


             reply	other threads:[~2007-11-23 20:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-23 20:10 Vladimir Prus [this message]
2007-11-26 18:51 ` Michael Snyder
2007-11-26 19:00   ` Vladimir Prus
2007-11-29 11:27   ` Vladimir Prus
2007-11-30  1:27     ` Michael Snyder
2007-11-30 10:04       ` Vladimir Prus

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=200711232310.17854.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.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