Re: MI: reporting of multiple breakpoints

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 17 Feb 2006 16:19:43 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: eliz@gnu.org, ghost@cs.msu.su, gdb@sources.redhat.com
> 
> > Exactly my point.  The case you're talking about is the opposite of
> > the one I was talking about.
> > 
> > The program runs, executes the store into foo.  GDB should report
> > hitting the watchpoint on foo, and should NOT report hitting the
> > breakpoint at 422.
> > 
> > User says "step".  We execute one instruction, which is the breakpoint
> > trap, and report that as the breakpoint at line 422.  User is happy.
> 
> No, this is not the opposite of what I described; could you explain why
> you think it is?  It's indistinguishable from what I described.  If we
> set the PC to the PC of the breakpoint, we assume we are past (have
> already hit) the breakpoint.  Therefore when we're stopped by a
> watchpoint at the PC of a breakpoint, it's sensible to treat this
> situation to the user as if we have already hit the breakpoint.

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

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

I agree.

> What you're suggesting would have two stops at identical PC values.

Right.

> You'd want to say continue and have GDB stop again, right away, without
> executing any instructions.  I'd find that much more confusing!

Agreed.