Re: MI: reporting of multiple breakpoints

Paul Koning
2006-02-17T20:16:22Z

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

Daniel> On Fri, Feb 17, 2006 at 03:01:50PM -0500, Paul Koning wrote:
>> I think it is wrong to step around a breakpoint that's set at a
>> different instruction than one that triggers a watchpoint. For
>> example, suppose I'm monitoring a variable by setting a
>> watchpoint, and setting up a command sequence to print an
>> expression and continue. Separate from that, I want the program
>> to break at line x.
>>
>> It is a bad thing for the break at x to fail due to the bad luck
>> of having a watch exception at the preceding instruction. If the
>> two stops happened to be the SAME instruction, then you have
>> plausible deniability. But not if they are different
>> instructions.

Daniel> This just doesn't scale. Now the user places two breakpoints
Daniel> at foo (via complicated scripts, say) and one of them has
Daniel> continue in its commands list. The user could make the exact
Daniel> same argument to complain that we "didn't stop".

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.

paul