Re: MI: reporting of multiple breakpoints

Eli Zaretskii
2006-02-18T11:10:20Z

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