Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Fri, Feb 17, 2006 at 03:01:50PM -0500, Paul Koning wrote:
 >> 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.

 Daniel> This just doesn't scale.  Now the user places two breakpoints
 Daniel> at foo (via complicated scripts, say) and one of them has
 Daniel> continue in its commands list.  The user could make the exact
 Daniel> same argument to complain that we "didn't stop".

That's not the same case.  I was going to say that both stops should
be reported even if they are at the SAME address, then decided against
that, as you did.

But in the case we're talking about, you could have this source code:

421    foo=1;
422    bar=2;

I set a breakpoint on line 422, and a watchpoint on "foo".  Clearly
those are very different -- line 422 doesn't touch foo, and the line
that touches foo isn't line 422.  GDB should not confuse those two
things.  If the hardware or GDB advances the PC across the watched
instruction, that's very well but that doesn't mean GDB should believe
the stop point is the instruction after.  The stop point is the store
into foo, which isn't line 422.

     paul