Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 >> Date: Fri, 17 Feb 2006 14:44:26 -0500 From: Daniel Jacobowitz
 >> <drow@false.org> Cc: Vladimir Prus <ghost@cs.msu.su>,
 >> gdb@sources.redhat.com
 >> 
 >> There are two events in hardware, yes - but "GDB will always see
 >> these two as separate events" is not accurate.  Suppose we've got
 >> an instruction at foo+0x10 that stores to a watched address and at
 >> foo+0x16 that has a breakpoint set on it.  The watchpoint will
 >> trigger, stopping GDB at foo+0x16.  At this point, we were stopped
 >> by the watchpoint, but we'll never hit the breakpoint - if the
 >> user "continue"s, GDB will politely step around the breakpoint.
 >> In effect, we've hit the watchpoint and breakpoint simultaneously,
 >> and IMO it would be appropriate to let the user know about both of
 >> them.

 Eli> Why do we step around the breakpoint?  As long as we do that,
 Eli> the breakpoint never happened, and we don't need to announce it.
 Eli> If we _want_ to announce it, we should stop stepping around it,
 Eli> IMHO.

I think it is wrong to step around a breakpoint that's set at a
different instruction than one that triggers a watchpoint.  For
example, suppose I'm monitoring a variable by setting a watchpoint,
and setting up a command sequence to print an expression and
continue.  Separate from that, I want the program to break at line x.

It is a bad thing for the break at x to fail due to the bad luck of
having a watch exception at the preceding instruction.  If the two
stops happened to be the SAME instruction, then you have plausible
deniability.  But not if they are different instructions.

	      paul