This is the mail archive of the
mailing list for the GDB project.
Re: RFD: infrun.c: No bpstat_stop_status call after proceed over break ?
- To: gdb-patches at sourceware dot cygnus dot com
- Subject: Re: RFD: infrun.c: No bpstat_stop_status call after proceed over break ?
- From: Jim Kingdon <kingdon at redhat dot com>
- Date: 15 Mar 2000 13:11:15 -0800
- Newsgroups: cygnus.patches.gdb
- Organization: Cygnus Solutions
- References: <200003130948.KAA07547@reisser.regent.e-technik.tu-muenchen.de>
> I am currently trying to fix a GDB bug with missing watchpoint triggers
> after proceeding over a breakpoint on x86 targets.
> Here is an example, using gdb.c++/annota2:
Yeah, I ran into the same bug (the testsuite hits it on x86 Linux).
My fix was similar to what you suggest (identical, unless I'm missing
something). I don't remember it as creating testsuite regressions but
I'm not sure I checked - it was a while ago that I looked into this.
RCS file: /cvs/gdb/gdb/gdb/infrun.c,v
retrieving revision 22.214.171.124
diff -u -r126.96.36.199 infrun.c
--- infrun.c 2000/02/05 07:29:43 188.8.131.52
+++ infrun.c 2000/02/07 13:22:02
@@ -2076,6 +2076,18 @@
+ /* We might not want to think about breakpoints, but what
+ about hardware watchpoints? We yanked out the hardware
+ (debug register or whatever) when we stepped over the breakpoint,
+ so we need to check manually the watchpoint condition (mildly
+ painful because it could get expensive, but I don't see how
+ using the hardware could work without lots of spaghetti trying
+ to keep track of what is inserted and what isn't (and how they
+ TODO: Need to think more about this, test it, &c. Right now it
+ is kind of an idea more so than a well-thought-out solution. */
/* Don't even think about breakpoints
if just proceeded over a breakpoint.
@@ -2087,6 +2099,7 @@
&& through_sigtramp_breakpoint == NULL)
+#endif /* 0 */
/* See if there is a breakpoint at the current PC. */
stop_bpstat = bpstat_stop_status