Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Feb 18, 2006 at 01:10:13PM +0200, Eli Zaretskii wrote:
> I think at the core of this argument is this problem: there's no PC
> value that is _between_ two adjacent instructions.  Thus, being
> _after_ an instruction at a certain value of PC means that we at the
> same time are _at_ or _on_ the next instruction at PC+1.  And being
> _at_ an instruction where we put a breakpoint means that the
> breakpoint have already triggered, since breakpoints are expected to
> break _before_ the instruction executes.
> 
> Do you both agree with this interpretation?

This I agree with completely.

> If so, you should also
> both agree that being _after_ an instruction that wrote into a watched
> data location also means we are at the same precise location where a
> breakpoint was already supposed to break.  There's nothing in between
> these two locations, no place where we could stop _before_ getting to
> a place where a breakpoint should break.

And this.

On Sat, Feb 18, 2006 at 01:33:37PM +0200, Eli Zaretskii wrote:
> No, it's not a hardware limitation, it's a ``limitation'' (I think
> it's rather a feature) of _any_ reasonable implementation of
> watchpoints, even software watchpoints: a watchpoint _always_ breaks
> _after_ the instruction that writes to the watched location.  It
> cannot be any other way, because no debugger and no hardware can
> possibly know whether an instruction will write to an arbitrary
> location before running that instruction.

While I agree with your conclusions above, this bit's not right.

(A) Hardware can pretty straightforwardly trigger the exception while
executing the instruction, between address calculation and store
completion, and back up the PC.  I have been poring over the MIPS
documentation, but I haven't worked out yet whether this happens
or not.  However, I think some platforms do - I think this is what
HAVE_NONSTEPPABLE_WATCHPOINT is all about. 
HAVE_CONTINUABLE_WATCHPOINT, on the other hand, is going to usually
imply that we stop after the event.

(B) Most targets have few store instructions.  Not x86, true.  But
for others, disassembling the instruction at $pc to see where it will
read or write is pretty trivial.  ARM has maybe a dozen relevant
instructions at most.

(C) Page protection write watchpoints will always fault before the
store, and the OS will often provide the faulting address for you
in the signal information.

Do we want to uniformly present watchpoints as after-the-store, as
a least common denominator and for consistency?  If so, a reasonable
sort of thing to do, then all of the first part of this message
applies.  If not, it applies to targets on which watchpoints stop
after execution...

> You seem to suggest that we back up one instruction after a watchpoint
> triggers.  Is that true?  If so, I think it's not a good idea, since
> (1) we'd have the watchpoint trigger again when we continue after
> that, and (2) the user who knows (as they all should, IMHO) that a
> watchpoint always triggers _after_ the code that wrote to the data
> will be utterly confused by that.

... except for this, which is the same problem I described for
breakpoints; that's a compelling reason to behave as we do now.

-- 
Daniel Jacobowitz
CodeSourcery