RE: Re: MI *stopped versus silent breakpoint

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

Hi,

I think you need two proceed().
This is because reverse-finish first sets a bp
at the method we want to 'finish' out of, and then
it does a single step backwards.  So, it looks like
it needs this double proceed.

The 'issue' I was bringing up is that a -silent-
breakpoint was not silent in MI.  But now, I agree it should
not be silent.  Instead it should print a full *stopped event.

Marc


-----Original Message-----
From: teawater [mailto:teawater@gmail.com]
Sent: Thu 2/5/2009 10:30 PM
To: Marc Khouzam
Cc: Daniel Jacobowitz; Vladimir Prus; gdb@sources.redhat.com; Pedro Alves; Michael Snyder
Subject: Re: Re: MI *stopped versus silent breakpoint
 
I remove the line "make_breakpoint_silent" from finish_backward.
Whant I got is:
(gdb)
reverse-finish
&"reverse-finish\n"
~"Run back to call of #0  cool () at 1.c:16\n"
^running
*running,thread-id="all"
(gdb)
~"\n"
~"Breakpoint 0, cool () at 1.c:9\n"
~"9\t{\n"
*stopped
*running,thread-id="all"
~"main () at 1.c:25\n"
~"25\t       b = cool ();\n"
*stopped
(gdb)

Does it resolve your trouble?

Actually, I am not very clear why you guys give silent breakpoints a
lot of attention.

I think the main issue is 2 "proceed" 2 "(gdb)".


Hui



On Fri, Feb 6, 2009 at 07:24, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
> 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
>
>