Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

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

 Eli> I think at the core of this argument is this problem: there's no
 Eli> PC value that is _between_ two adjacent instructions.  

No, that isn't my point.

My point is that, at least on some of the platforms, a watchpoint
exception will deliver the PC of the instruction doing the store, or
that PC can be deduced.  Therefore, on such platforms, that is the PC
that should be reported, which will make the report point to the right
source line.  Of course, the resume will not resume there, but GDB
already has machinery for that.

Daniel's comments are entirely valid for the case where you cannot
know the PC of the store -- certainly in that case you may end up with
a PC that happens to match that of a breakpoint, and in that case you
may end up reporting the watchpoint stop at the break line, and end up
not doing the break when you resume.  Fine, if that's the best your
hardware permits, but that isn't universally true.

	 paul