Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning@equallogic.com>]

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

 Daniel> No, this is not the opposite of what I described; could you
 Daniel> explain why you think it is?  It's indistinguishable from
 Daniel> what I described.  If we set the PC to the PC of the
 Daniel> breakpoint, we assume we are past (have already hit) the
 Daniel> breakpoint.  Therefore when we're stopped by a watchpoint at
 Daniel> the PC of a breakpoint, it's sensible to treat this situation
 Daniel> to the user as if we have already hit the breakpoint.

You talked about a case where a user sets $pc.  That doesn't show up
in my discussion at all.  The program is just running, and hits a
watchpoint triggered by an action in source line 421.  It is really a
bad idea to pretend that we've stopped at a breakpoint on line 422.

The fact that some hardware may take the exception with PC pointing at
422 is not a valid reason to do otherwise.  It's conceivable that it's
unavoidable, if the hardware doesn't distinguish watchpoint from
breakpoint exceptions.  But, for example, on MIPS the two are
distinct.  So if I get a watch exception at PC 0x12340, I know that
the instruction that caused the watch is 0x1233c, which is line 421,
so that's what should be reported.  

The instruction that caused the exception is NOT the break, first of
all because it's at 0x12340 which is not the instruction address that
caused the exception, and second because the exception type (watch
exception) cannot be produced by a break instruction.

 Daniel> What I'm maintaining is that we shouldn't "sort this out".
 Daniel> What we display should be, IMO, all the events which we
 Daniel> consider to have logically occurred in the current
 Daniel> conditions.  The value of a watchpoint has changed since we
 Daniel> last checked it?  Report the watchpoint.  We've reached the
 Daniel> PC of a breakpoint?  Report the breakpoint.

 Daniel> What you're suggesting would have two stops at identical PC
 Daniel> values.  You'd want to say continue and have GDB stop again,
 Daniel> right away, without executing any instructions.  I'd find
 Daniel> that much more confusing!

Maybe you find it confusing because you're trying to reason about this
at the machine code level.  Look at the source line level instead.  

If you watch foo, you should be told about watchpoint stops at lines
that touch foo.  You should not be told about breaks in other lines.
If you hit at watchpoint in line 421, and you continue, and you had
defined a breakpoint in line 422, you would expect that breakpoint to
fire because 422 != 421.

For that matter, if you do this, then in fact you DID execute one
instruction, namely the break instruction.  Also, if you recognize
that watch exceptions are caused by the instruction at PC-size, and
break instructions are caused by the instruction at PC, it all makes
even more sense -- the triggering instruction is NOT the same, and if
you take BOTH the exception type AND the exception PC into account in
the analysis, you will get the correct answer.

As far as I remember from the break/watch analysis code, this is all
perfectly doable, even if it isn't the way it's currently coded.  

	  paul