Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz <drow@false.org>]

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

It's precisely because I am reasoning about this at the source code
level that I find it confusing; we are stopped at the source location
of the breakpoint.  The fact that the breakpoint hasn't physically
triggered is, as far as I'm concerned, just an implementation detail.
Please take another look at my single-step example in the last message.

> 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.

But you don't "hit a watchpoint in line 421".  When you hit the
watchpoint, you are already at line 422.  There's no way to "back up"
the view we prevent to the user (excluding simulators); for instance
the store may have been in the branch delay slot, so we could have come
from absolutely anywhere.  Other architectures may trigger the
watchpoint multiple cycles later when the pipeline has cleared up a
bit.  Your later comment that "watch exceptions are caused by the
instruction at PC-size" assumes far too much.

If there were a way to back up the view, and we did it, then of course
I'd agree we weren't stopped at the breakpoint.

-- 
Daniel Jacobowitz
CodeSourcery