RE: Re: MI *stopped versus silent breakpoint

["Marc Khouzam" <marc.khouzam@ericsson.com>]

From: Daniel Jacobowitz Thu 2/5/2009 5:42 PM
> On Thu, Feb 05, 2009 at 05:29:26PM -0500, Marc Khouzam wrote:
> > Hi,
> > 
> > I'm curious as to the motivation behind silent breakpoints.
> > I'm trying to understand why a frontend would need to know
> > of a silent bp hit, but not a user?
> > For instance, in async mode, if a silent bp is used,
> > how would the user ever know it is hit?  And if the user
> > need not know, why would a frontend?
> 
> Mostly, they're for commands lists that automatically resume.  For
> instance, if you want to increment a counter every time a breakpoint
> is hit, you might mark it as:
> 
> silent
> commands
> set $i++
> continue
> end
> 
> What to do with MI notifications in this case, I don't know...

In the scenario you mention, having a proper *stopped event for 
silent bp would pretty much be unnoticed by the user thanks to the 
*running event that immediately follows (the frontend would stop and 
resume right away.)  Same situation for the reverse-finish situation.

What we have now is an empty *stopped event and that is not much 
use for a frontend and would probably cause more confusion than good.

So, based on Volodya's explanation (that I agree with), and Daniel's
explanation, it seems that there should be a *stopped event for 
silent bp, as long as it is complete.  Or at least that is what
I believe.

Thanks for your explanations.

Marc