This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: reporting of multiple breakpoints


On Fri, Feb 17, 2006 at 09:56:46PM +0200, Eli Zaretskii wrote:
> > 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.
> 
> Why do we step around the breakpoint?  As long as we do that, the
> breakpoint never happened, and we don't need to announce it.  If we
> _want_ to announce it, we should stop stepping around it, IMHO.

All this long predates me, you understand.  I can only give you my
interpretation, not a real reason.  But the status quo seems reasonable
enough to me.

Consider a store which causes two user-placed watchpoints to trigger -
this is pretty easy since there is a non-trivial mapping between user
watchpoints and watched values.  We want to report both watchpoints.
But we were, physically, only stopped for one of them.

It's the same thing with breakpoints.  A breakpoint is "stop the
program when you reach address FOO".  We've reached address FOO; the
fact that something _else_ caused us to stop at the same time seems
only marginally relevant.

We step around it because we want to announce the breakpoint when
we first reach the relevant PC; if we're at FOO and say continue
then normally we won't hit the breakpoint at FOO, because after
hitting that breakpoint we present $pc == FOO to the user.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]