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

[Daniel Jacobowitz <drow at mvista dot com>]

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