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


> 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.

And indeed we do announce both watchpoints today, right?

> 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?


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