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
next 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