This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI *stopped versus silent breakpoint


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]