RE: Re: MI *stopped versus silent breakpoint

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

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