Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz <drow@false.org>]

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

So?

The user does "set $var = $pc" after hitting the breakpoint at bar.
Then later they do jump *$var.  They have every right (IMO) to expect
that they are, once again, after the breakpoint at line 422, and that
it won't be hit again - and even though you could make a good argument
for the opposite case, this is how GDB has behaved for a long while.
I think you'll encounter just as manage strange cases if you reverse
it.

Another way to think about it, if this helps.  Right now you will not
hit a GDB-requested event after "step" or "continue" without executing
at least one instruction.  You might be interrupted (by a trap
instruction, an async signal, et cetera).  But GDB will do its level
best to step when you ask for a step, not hit a breakpoint that
you've already noticed.

-- 
Daniel Jacobowitz
CodeSourcery