Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning@equallogic.com>]

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

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

 Daniel> It's precisely because I am reasoning about this at the
 Daniel> source code level that I find it confusing; we are stopped at
 Daniel> the source location of the breakpoint.  The fact that the
 Daniel> breakpoint hasn't physically triggered is, as far as I'm
 Daniel> concerned, just an implementation detail.  Please take
 Daniel> 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.

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

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

I see the point.  If you have hardware that has imprecise watchpoint
exceptions, then indeed you're hosed.  You might be anywhere, and in
that case the watchpoint feature is going to be quite unuseable
because the user will be pointed at a source line that is potentially
not even in the same source file as the triggering instruction.

However, the fact that some architectures have imprecise watchpoints
is no reason to force imprecision on those that can do better.  In
other words, this should be an example of target-dependent machinery:
if the target has the ability to determine the "PC of the watchpoint
trigger instruction" then it should do so, and the break/watch display
reporting machinery should use that information to report the
watchpoint at the "correct" source line.

I thought such machinery already existed, but I may be mixed up with
other target hooks or target macros that deal with advancing or
backing up the PC at breakpoints and watchpoints.

	paul