This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Re: MI *stopped versus silent breakpoint
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