MI *stopped versus silent breakpoint

MI *stopped versus silent breakpoint

[Marc Khouzam]

Hi,

I just found out that a breakpoint can be made silent, in which case
there
is no breakpoint output when it is hit.  When doing a reverse-finish 
operation, a silent breakpoint is used, and when hit the inferior is
resumed
automatically, and then a single-step is done.

In CLI, it makes it look like the inferior stopped only once, instead of
twice.

In MI though, with the *stopped events, we do get an empty
*stopped for the silent breakpoint.  So I see two *stopped events
consecutively.

I wondered if a silent breakpoint should in fact generate a *stopped
event
or not?  For a frontend, it can be confusing to see two stopped events.
FYI, what I did for DSF-GDB and reverse debugging, is to ignore empty
*stopped.
I stilled wondered about GDB though.

Marc


 

 

Re: MI *stopped versus silent breakpoint

[teawater]

Hi Marc,

When I try reverse-debug with MI what I got is:
(gdb)
reverse-finish
&"reverse-finish\n"
~"Run back to call of #0  cool () at 1.c:15\n"
^running
*running,thread-id="all"
(gdb)
*stopped
*running,thread-id="all"
~"main () at 1.c:25\n"
~"25\t       b = cool ();\n"
*stopped
(gdb)

Could you give me some example about what you talk about ?


Thanks,
Hui

On Wed, Jan 21, 2009 at 23:41, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
> Hi,
>
> I just found out that a breakpoint can be made silent, in which case
> there
> is no breakpoint output when it is hit.  When doing a reverse-finish
> operation, a silent breakpoint is used, and when hit the inferior is
> resumed
> automatically, and then a single-step is done.
>
> In CLI, it makes it look like the inferior stopped only once, instead of
> twice.
>
> In MI though, with the *stopped events, we do get an empty
> *stopped for the silent breakpoint.  So I see two *stopped events
> consecutively.
>
> I wondered if a silent breakpoint should in fact generate a *stopped
> event
> or not?  For a frontend, it can be confusing to see two stopped events.
> FYI, what I did for DSF-GDB and reverse debugging, is to ignore empty
> *stopped.
> I stilled wondered about GDB though.
>
> Marc
>
>
>
>
>
>
>

RE: MI *stopped versus silent breakpoint

[Marc Khouzam]

Hi,

if you look at your example output below,
there is two *stopped events and two *running events,
although you only issued one reverse-finish.

From a user perspective, there should be one *stopped
and one *running.  So, for the frontend, multiple
events are not exact; but the frontend can be made
smart enough to ignore them.

Marc


-----Original Message-----
From: teawater [mailto:teawater@gmail.com]
Sent: Tue 2/3/2009 12:36 AM
To: Marc Khouzam
Cc: gdb@sourceware.org
Subject: Re: MI *stopped versus silent breakpoint
 
Hi Marc,

When I try reverse-debug with MI what I got is:
(gdb)
reverse-finish
&"reverse-finish\n"
~"Run back to call of #0  cool () at 1.c:15\n"
^running
*running,thread-id="all"
(gdb)
*stopped
*running,thread-id="all"
~"main () at 1.c:25\n"
~"25\t       b = cool ();\n"
*stopped
(gdb)

Could you give me some example about what you talk about ?


Thanks,
Hui

On Wed, Jan 21, 2009 at 23:41, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
> Hi,
>
> I just found out that a breakpoint can be made silent, in which case
> there
> is no breakpoint output when it is hit.  When doing a reverse-finish
> operation, a silent breakpoint is used, and when hit the inferior is
> resumed
> automatically, and then a single-step is done.
>
> In CLI, it makes it look like the inferior stopped only once, instead of
> twice.
>
> In MI though, with the *stopped events, we do get an empty
> *stopped for the silent breakpoint.  So I see two *stopped events
> consecutively.
>
> I wondered if a silent breakpoint should in fact generate a *stopped
> event
> or not?  For a frontend, it can be confusing to see two stopped events.
> FYI, what I did for DSF-GDB and reverse debugging, is to ignore empty
> *stopped.
> I stilled wondered about GDB though.
>
> Marc
>
>
>
>
>
>
>

Re: MI *stopped versus silent breakpoint

[teawater]

Hi Marc,

I read the source code in infcmd.c:finish_backward.
This is because function "proceed" will be call twice in
"finish_backward". Maybe MI output depend some
observer_notify_target_xxx function. So it output twice.

So, do you think it affect your work very much?

Pedro and Vladimir, sorry to disturb you. This issue have some
relation with MI.  Could you please give us some help in it?

Thanks,
Hui





On Tue, Feb 3, 2009 at 19:47, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
> Hi,
>
> if you look at your example output below,
> there is two *stopped events and two *running events,
> although you only issued one reverse-finish.
>
> From a user perspective, there should be one *stopped
> and one *running.  So, for the frontend, multiple
> events are not exact; but the frontend can be made
> smart enough to ignore them.
>
> Marc
>
>
> -----Original Message-----
> From: teawater [mailto:teawater@gmail.com]
> Sent: Tue 2/3/2009 12:36 AM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: MI *stopped versus silent breakpoint
>
> Hi Marc,
>
> When I try reverse-debug with MI what I got is:
> (gdb)
> reverse-finish
> &"reverse-finish\n"
> ~"Run back to call of #0  cool () at 1.c:15\n"
> ^running
> *running,thread-id="all"
> (gdb)
> *stopped
> *running,thread-id="all"
> ~"main () at 1.c:25\n"
> ~"25\t       b = cool ();\n"
> *stopped
> (gdb)
>
> Could you give me some example about what you talk about ?
>
>
> Thanks,
> Hui
>
> On Wed, Jan 21, 2009 at 23:41, Marc Khouzam <marc.khouzam@ericsson.com> wrote:
>> Hi,
>>
>> I just found out that a breakpoint can be made silent, in which case
>> there
>> is no breakpoint output when it is hit.  When doing a reverse-finish
>> operation, a silent breakpoint is used, and when hit the inferior is
>> resumed
>> automatically, and then a single-step is done.
>>
>> In CLI, it makes it look like the inferior stopped only once, instead of
>> twice.
>>
>> In MI though, with the *stopped events, we do get an empty
>> *stopped for the silent breakpoint.  So I see two *stopped events
>> consecutively.
>>
>> I wondered if a silent breakpoint should in fact generate a *stopped
>> event
>> or not?  For a frontend, it can be confusing to see two stopped events.
>> FYI, what I did for DSF-GDB and reverse debugging, is to ignore empty
>> *stopped.
>> I stilled wondered about GDB though.
>>
>> Marc
>>
>>
>>
>>
>>
>>
>>
>
>

Re: MI *stopped versus silent breakpoint

[Vladimir Prus]

On Thursday 05 February 2009 11:09:56 teawater wrote:
> Hi Marc,
> 
> I read the source code in infcmd.c:finish_backward.
> This is because function "proceed" will be call twice in
> "finish_backward". Maybe MI output depend some
> observer_notify_target_xxx function. So it output twice.

The *stopped notification is output as result of call to

	observer_notify_normal_stop

which is done in infrun.c:normal_stop. I do believe that "silent" breakpoint
should generate *stopped, since otherwise frontend will assume the target is
running. Furthermore, I believe that silent breakpoints, in MI, should behave
identically to ordinary breakpoints -- as it stands, we print *stopped without
frame information.


I don't know why a silent breakpoint is used in implementation of reverse-finish,
nor do I understand why normal_stop is called in the middle of reverse-finish when
stopping on that temporary breakpoint. I think the first fix it to make reverse-finish
not to call normal_stop on that internal breakpoint (just like normal_stop is not
called on solib load breakpoint).

- Volodya

Re: MI *stopped versus silent breakpoint

[teawater]

On Thu, Feb 5, 2009 at 17:25, Vladimir Prus <vladimir@codesourcery.com> wrote:
> On Thursday 05 February 2009 11:09:56 teawater wrote:
>> Hi Marc,
>>
>> I read the source code in infcmd.c:finish_backward.
>> This is because function "proceed" will be call twice in
>> "finish_backward". Maybe MI output depend some
>> observer_notify_target_xxx function. So it output twice.
>
> The *stopped notification is output as result of call to
>
>        observer_notify_normal_stop
>
> which is done in infrun.c:normal_stop. I do believe that "silent" breakpoint
> should generate *stopped, since otherwise frontend will assume the target is
> running. Furthermore, I believe that silent breakpoints, in MI, should behave
> identically to ordinary breakpoints -- as it stands, we print *stopped without
> frame information.
>
>
> I don't know why a silent breakpoint is used in implementation of reverse-finish,
> nor do I understand why normal_stop is called in the middle of reverse-finish when
> stopping on that temporary breakpoint. I think the first fix it to make reverse-finish
> not to call normal_stop on that internal breakpoint (just like normal_stop is not
> called on solib load breakpoint).

The normal_stop is called twice in reverse-finish because
finish_backward call "proceed" twice, "proceed" call normal_stop.

Hui

Re: MI *stopped versus silent breakpoint

[Vladimir Prus]

teawater wrote:

> On Thu, Feb 5, 2009 at 17:25, Vladimir Prus <vladimir@codesourcery.com> wrote:
>> On Thursday 05 February 2009 11:09:56 teawater wrote:
>>> Hi Marc,
>>>
>>> I read the source code in infcmd.c:finish_backward.
>>> This is because function "proceed" will be call twice in
>>> "finish_backward". Maybe MI output depend some
>>> observer_notify_target_xxx function. So it output twice.
>>
>> The *stopped notification is output as result of call to
>>
>>        observer_notify_normal_stop
>>
>> which is done in infrun.c:normal_stop. I do believe that "silent" breakpoint
>> should generate *stopped, since otherwise frontend will assume the target is
>> running. Furthermore, I believe that silent breakpoints, in MI, should behave
>> identically to ordinary breakpoints -- as it stands, we print *stopped without
>> frame information.
>>
>>
>> I don't know why a silent breakpoint is used in implementation of reverse-finish,
>> nor do I understand why normal_stop is called in the middle of reverse-finish when
>> stopping on that temporary breakpoint. I think the first fix it to make reverse-finish
>> not to call normal_stop on that internal breakpoint (just like normal_stop is not
>> called on solib load breakpoint).
> 
> The normal_stop is called twice in reverse-finish because
> finish_backward call "proceed" twice, "proceed" call normal_stop.

Then I presume you get to change that. I don't see any way we can overload
'silent' breakpoint to output something in most cases, except for reverse-finish.
And if you are going to add some flag to indicate breakpoints used for single-step,
you might as well change handle_inferiour_event to do extra reverse step when such
breakpoint is hit.

- Volodya

Re: MI *stopped versus silent breakpoint

[teawater]

On Thu, Feb 5, 2009 at 17:35, Vladimir Prus <vladimir@codesourcery.com> wrote:
> teawater wrote:
>
>> On Thu, Feb 5, 2009 at 17:25, Vladimir Prus <vladimir@codesourcery.com> wrote:
>>> On Thursday 05 February 2009 11:09:56 teawater wrote:
>>>> Hi Marc,
>>>>
>>>> I read the source code in infcmd.c:finish_backward.
>>>> This is because function "proceed" will be call twice in
>>>> "finish_backward". Maybe MI output depend some
>>>> observer_notify_target_xxx function. So it output twice.
>>>
>>> The *stopped notification is output as result of call to
>>>
>>>        observer_notify_normal_stop
>>>
>>> which is done in infrun.c:normal_stop. I do believe that "silent" breakpoint
>>> should generate *stopped, since otherwise frontend will assume the target is
>>> running. Furthermore, I believe that silent breakpoints, in MI, should behave
>>> identically to ordinary breakpoints -- as it stands, we print *stopped without
>>> frame information.
>>>
>>>
>>> I don't know why a silent breakpoint is used in implementation of reverse-finish,
>>> nor do I understand why normal_stop is called in the middle of reverse-finish when
>>> stopping on that temporary breakpoint. I think the first fix it to make reverse-finish
>>> not to call normal_stop on that internal breakpoint (just like normal_stop is not
>>> called on solib load breakpoint).
>>
>> The normal_stop is called twice in reverse-finish because
>> finish_backward call "proceed" twice, "proceed" call normal_stop.
>
> Then I presume you get to change that. I don't see any way we can overload
> 'silent' breakpoint to output something in most cases, except for reverse-finish.
> And if you are going to add some flag to indicate breakpoints used for single-step,
> you might as well change handle_inferiour_event to do extra reverse step when such
> breakpoint is hit.
>

I am not very clear about function "finish_backward". But maybe I can
try with it.

Michael, sorry for forget mail you about this issue, do you have some
idea with it?

Hui

RE: Re: MI *stopped versus silent breakpoint

[Marc Khouzam]

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?

I do see that a frontend would probably 'hang' if it thought
the inferior was running when it wasn't.  However, if silent
bp are aimed at allowing GDB to resume execution without
it being visible to the user/frontend, then we may want to
re-think the *stopped event in that case.

Again, I fixed it for Eclipse, so this is more of a question
towards improving GDB, if needed.

Thanks


-----Original Message-----
From: gdb-owner@sourceware.org on behalf of Vladimir Prus
Sent: Thu 2/5/2009 4:35 AM
To: gdb@sources.redhat.com
Subject:  Re: MI *stopped versus silent breakpoint
 
teawater wrote:

> On Thu, Feb 5, 2009 at 17:25, Vladimir Prus <vladimir@codesourcery.com> wrote:
>> On Thursday 05 February 2009 11:09:56 teawater wrote:
>>> Hi Marc,
>>>
>>> I read the source code in infcmd.c:finish_backward.
>>> This is because function "proceed" will be call twice in
>>> "finish_backward". Maybe MI output depend some
>>> observer_notify_target_xxx function. So it output twice.
>>
>> The *stopped notification is output as result of call to
>>
>>        observer_notify_normal_stop
>>
>> which is done in infrun.c:normal_stop. I do believe that "silent" breakpoint
>> should generate *stopped, since otherwise frontend will assume the target is
>> running. Furthermore, I believe that silent breakpoints, in MI, should behave
>> identically to ordinary breakpoints -- as it stands, we print *stopped without
>> frame information.
>>
>>
>> I don't know why a silent breakpoint is used in implementation of reverse-finish,
>> nor do I understand why normal_stop is called in the middle of reverse-finish when
>> stopping on that temporary breakpoint. I think the first fix it to make reverse-finish
>> not to call normal_stop on that internal breakpoint (just like normal_stop is not
>> called on solib load breakpoint).
> 
> The normal_stop is called twice in reverse-finish because
> finish_backward call "proceed" twice, "proceed" call normal_stop.

Then I presume you get to change that. I don't see any way we can overload
'silent' breakpoint to output something in most cases, except for reverse-finish.
And if you are going to add some flag to indicate breakpoints used for single-step,
you might as well change handle_inferiour_event to do extra reverse step when such
breakpoint is hit.

- Volodya

Re: Re: MI *stopped versus silent breakpoint

[Daniel Jacobowitz]

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

-- 
Daniel Jacobowitz
CodeSourcery

RE: Re: MI *stopped versus silent breakpoint

[Marc Khouzam]

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

Re: Re: MI *stopped versus silent breakpoint

[Daniel Jacobowitz]

On Thu, Feb 05, 2009 at 06:24:41PM -0500, Marc Khouzam wrote:
> 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.

Is any FE likely to get upset that threads resume without its
"permission"?  You'd probably see the *stopped, try to get a stack
frame, and then get a *running instead...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Re: MI *stopped versus silent breakpoint

[teawater]

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

RE: Re: MI *stopped versus silent breakpoint

[Marc Khouzam]

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

Re: MI *stopped versus silent breakpoint

[Vladimir Prus]

On Friday 06 February 2009 10:45:49 Marc Khouzam wrote:
> 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.

This proves that the target should be resumed twice. It does not prove that
a function called proceed() should be called twice nor that a function called
normal_stop should be called twice.

- Volodya