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 10:19:12PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 17 Feb 2006 15:05:58 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> > 
> > 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.
> 
> No, I think we were stopped by both of them.  They both watch the same
> address, so they both fired when the location gets written.

If they were set using the same watchpoint register, they "both"
triggered trivially.  If they were set using different hardware
watchpoint resources, then the target almost certainly reported only
one of them.

> And indeed we do announce both watchpoints today, right?

Yes, that's why I was drawing the parallel.

> > 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.
> 
> But what about the commands associated with that breakpoint?  We've
> reached the address and stopped, allright, but we didn't run the
> commands the user wanted us to, did we?

We should run them when we stop.  That's what I'm trying to say :-)

-- 
Daniel Jacobowitz
CodeSourcery


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