Re: MI: reporting of multiple breakpoints

[Paul Koning <pkoning@equallogic.com>]

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

 Daniel> On Fri, Feb 17, 2006 at 03:16:15PM -0500, Paul Koning wrote:
 >> That's not the same case.  I was going to say that both stops
 >> should be reported even if they are at the SAME address, then
 >> decided against that, as you did.
 >> 
 >> But in the case we're talking about, you could have this source
 >> code:
 >> 
 >> 421 foo=1; 
 >> 422 bar=2;
 >> 
 >> I set a breakpoint on line 422, and a watchpoint on "foo".
 >> Clearly those are very different -- line 422 doesn't touch foo,
 >> and the line that touches foo isn't line 422.  GDB should not
 >> confuse those two things.  If the hardware or GDB advances the PC
 >> across the watched instruction, that's very well but that doesn't
 >> mean GDB should believe the stop point is the instruction after.
 >> The stop point is the store into foo, which isn't line 422.

 Daniel> So?

 Daniel> The user does "set $var = $pc" after hitting the breakpoint
 Daniel> at bar.  Then later they do jump *$var.  They have every
 Daniel> right (IMO) to expect that they are, once again, after the
 Daniel> breakpoint at line 422, and that it won't be hit again - and
 Daniel> even though you could make a good argument for the opposite
 Daniel> case, this is how GDB has behaved for a long while.  I think
 Daniel> you'll encounter just as manage strange cases if you reverse
 Daniel> it.

 Daniel> Another way to think about it, if this helps.  Right now you
 Daniel> will not hit a GDB-requested event after "step" or "continue"
 Daniel> without executing at least one instruction.  You might be
 Daniel> interrupted (by a trap instruction, an async signal, et
 Daniel> cetera).  But GDB will do its level best to step when you ask
 Daniel> for a step, not hit a breakpoint that you've already noticed.

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.

Maybe I'm messing up the discussion by being confused about what the
problem is that started the thread.  I thought what I heard is: the
watchpoint traps with the PC pointing *after* the store, i.e., it
points at the trap instruction, so it looks like two simultaneous
stops.  

My point is that this is not correct reasoning: the watchpoint stop is
at PC-instruction_size, which is in line 421 (last instruction of 421)
and clearly different from line 422.  Yes, the hardware reports PC,
not PC-instruction_size, but that's GDB's job to sort out, not the
user's.

	paul