This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI: reporting of multiple breakpoints
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.
So?
The user does "set $var = $pc" after hitting the breakpoint at bar.
Then later they do jump *$var. They have every right (IMO) to expect
that they are, once again, after the breakpoint at line 422, and that
it won't be hit again - and even though you could make a good argument
for the opposite case, this is how GDB has behaved for a long while.
I think you'll encounter just as manage strange cases if you reverse
it.
Another way to think about it, if this helps. Right now you will not
hit a GDB-requested event after "step" or "continue" without executing
at least one instruction. You might be interrupted (by a trap
instruction, an async signal, et cetera). But GDB will do its level
best to step when you ask for a step, not hit a breakpoint that
you've already noticed.
--
Daniel Jacobowitz
CodeSourcery