Re: MI: reporting of multiple breakpoints

Paul Koning
2006-02-17T20:02:00Z

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

>> Date: Fri, 17 Feb 2006 14:44:26 -0500 From: Daniel Jacobowitz
>> <drow@false.org> Cc: Vladimir Prus <ghost@cs.msu.su>,
>> gdb@sources.redhat.com
>>
>> There are two events in hardware, yes - but "GDB will always see
>> these two as separate events" is not accurate. Suppose we've got
>> an instruction at foo+0x10 that stores to a watched address and at
>> foo+0x16 that has a breakpoint set on it. The watchpoint will
>> trigger, stopping GDB at foo+0x16. At this point, we were stopped
>> by the watchpoint, but we'll never hit the breakpoint - if the
>> user "continue"s, GDB will politely step around the breakpoint.
>> In effect, we've hit the watchpoint and breakpoint simultaneously,
>> and IMO it would be appropriate to let the user know about both of
>> them.

Eli> Why do we step around the breakpoint? As long as we do that,
Eli> the breakpoint never happened, and we don't need to announce it.
Eli> If we _want_ to announce it, we should stop stepping around it,
Eli> IMHO.

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.

paul