Re: [RFA] Fix watchpoints when stepping over a breakpoint

Daniel Jacobowitz
2002-04-05T15:54:11Z

On Fri, Apr 05, 2002 at 10:34:30AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Apr 2002 18:43:33 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> >
> > When I tried it I got stuck
> > on the bp_shlib_event breakpoint. We would hit it, remove, single-step
> > (trap expected), check where we were... and find ourselves at the
> > shared library breakpoint again because of DECR_PC_AFTER_BREAK!
> >
> > Instead, I now collect only non-breakpoint events.
>
> Isn't this a bit ad hoc? I think the issue of doing TRT when both a
> breakpoint and a watchpoint fire for the same instruction needs a more
> general solution. While ignoring breakpoints might be the Right Thing
> in this particular case, I wonder what will be TRT in other cases?
>
> Did you try to arrange for a normal breakpoint and a watchpoint on the
> same instruction, and see what happens in that case, with and without
> this patch?

Yes, I did - that's 'watch a.x' in gdb.c++/annota2.exp. Without the
patch it fails on i386-linux, with it it passes.

I don't really think it's any more ad-hoc than the trap_expected flag.
If trap_expected is set, then we expected to stop on the next
instruction because of some property of (either single-stepping or)
that instruction. Breakpoints are also a property of that instruction;
so we ignore them when checking for any other interesting reason to
have stopped. Watchpoints, on the other hand, are clearly different.

--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer