Re: MI: reporting of multiple breakpoints

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Feb 17, 2006 at 04:14:42PM -0500, Paul Koning wrote:
>  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.

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.

Try single-stepping up to a breakpoint if that clarifies things:

4       main (int argc, char **argv)
5       {
6         printf ("Hello world\n");
7         return 0;
8       }
(gdb) b 7
Breakpoint 2 at 0x80483a4: file debugging/printf.c, line 7.
(gdb) s
Hello world

Breakpoint 2, main (argc=1, argv=0xbfe9b154) at debugging/printf.c:7
7         return 0;

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

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.

What you're suggesting would have two stops at identical PC values.
You'd want to say continue and have GDB stop again, right away, without
executing any instructions.  I'd find that much more confusing!

-- 
Daniel Jacobowitz
CodeSourcery