[RFC] Inferior stop events

[RFC] Inferior stop events

[Keith Seitz]

Hi,

The next part of my ongoing quest to get information out of gdb:
inferior_stop events. These events are to inform a UI that the inferior
has stopped running and why it has stopped.

I propose to take "enum stop_reason" from infrun.c and move it into
inferior.h. This enum will be used by both print_stop_reason (which is
really a cli function) and user interfaces, like Insight. (Pretend I
didn't say that.)

It is then my intention to litter infrun.c with event notifications, which
provide a reason for the stop, and some supplemental info on the stop
(signal, exit status, breakpoint#, etc).

Does this sound like a reasonable approach?

Your comments and recommendations appreciated.
Keith

Re: [RFC] Inferior stop events

[Eli Zaretskii]

On Wed, 13 Jun 2001, Keith Seitz wrote:

> Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm
> Sender: gdb-owner@sources.redhat.com
> X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs
> Date: Wed, 13 Jun 2001 13:45:36 -0700 (PDT)
> From: Keith Seitz <keiths@cygnus.com>
> 
> Hi,
> 
> The next part of my ongoing quest to get information out of gdb:
> inferior_stop events. These events are to inform a UI that the inferior
> has stopped running and why it has stopped.
> 
> I propose to take "enum stop_reason" from infrun.c and move it into
> inferior.h. This enum will be used by both print_stop_reason (which is
> really a cli function) and user interfaces, like Insight. (Pretend I
> didn't say that.)
> 
> It is then my intention to litter infrun.c with event notifications, which
> provide a reason for the stop, and some supplemental info on the stop
> (signal, exit status, breakpoint#, etc).

For the benefit of the GUI-challenged people such as myself: how, if at
all, is this done now?  That is, what does a typical UI for GDB do to
tell the user why did the debuggee stopped?

Re: [RFC] Inferior stop events

[Keith Seitz]

On Thu, 14 Jun 2001, Eli Zaretskii wrote:

> For the benefit of the GUI-challenged people such as myself: how, if at
> all, is this done now?  That is, what does a typical UI for GDB do to
> tell the user why did the debuggee stopped?

I can only speak for Insight. We use the call_command_hook, and we assume
that the target will run if the command's class is class_run or
class_trace.

Before calling the actual function bound to the command, we run a script
to tell the rest of the UI that we are about to be "busy". When the
command is done (and the function returns), we tell the UI that it is
idle. This tells us that gdb is no longer using the inferior, but it does
not tell us what happened. Did it exit? Hit a breakpoint? Take a signal?

Mind you, some of these things we can sort of figure out. For example,
when the inferior gets a signal, we have a hook which runs in the global
context. At one time, we attempted to parse the output of "info targ". All
kinds of nasty things. IMO this is much cleaner.

Hope this helps.
Keith

Re: [RFC] Inferior stop events

[Eli Zaretskii]

> Date: Thu, 14 Jun 2001 08:13:14 -0700 (PDT)
> From: Keith Seitz <keiths@cygnus.com>
> 
> Mind you, some of these things we can sort of figure out. For example,
> when the inferior gets a signal, we have a hook which runs in the global
> context. At one time, we attempted to parse the output of "info targ". All
> kinds of nasty things. IMO this is much cleaner.

It surely is cleaner.

Thanks for taking time to explain this.

Re: [RFC] Inferior stop events

[Andrew Cagney]

[I'm going to add Insight as this is really an insight architecture question]


> Hi,
> 
> The next part of my ongoing quest to get information out of gdb:
> inferior_stop events. These events are to inform a UI that the inferior
> has stopped running and why it has stopped.
> 
> I propose to take "enum stop_reason" from infrun.c and move it into
> inferior.h. This enum will be used by both print_stop_reason (which is
> really a cli function) and user interfaces, like Insight. (Pretend I
> didn't say that.)
> 
> It is then my intention to litter infrun.c with event notifications, which
> provide a reason for the stop, and some supplemental info on the stop
> (signal, exit status, breakpoint#, etc).
> 
> Does this sound like a reasonable approach?


It sounds wrong.  Have you looked at what MI did?


> Your comments and recommendations appreciated.
> Keith


Keith,

The thing I don't understand in all this is how GDB / Insight will be 
coupled together.  Right now I would draw things as:

	Insight
	   |
	hook()
	  |
	GDB internals
	  |
	Event Loop

 
I think everyone agreed this was wrong long ago.  It should be:


	GDB Internals -> message -> Insight
	   |                           |
	   -------- Event Loop ---------


That is, instead of Insight sitting on top of GDB processing stuff 
instantly, Insight would sit adjacent to GDB, allow GDB to complete its 
processing and *then* start processing any events it has outstanding.

In such a model, I don't think any (or very few) hooks are needed. 
Insight can find out the stop reason by asking GDB (just like MI did). 
All GDB needs to do is tell insight that the program state changed.

	Andrew

Re: [RFC] Inferior stop events

[Keith Seitz]

On Thu, 14 Jun 2001, Andrew Cagney wrote:

> I think everyone agreed this was wrong long ago.  It should be:
>
>
> 	GDB Internals -> message -> Insight
> 	   |                           |
> 	   -------- Event Loop ---------
>
>
> That is, instead of Insight sitting on top of GDB processing stuff
> instantly, Insight would sit adjacent to GDB, allow GDB to complete its
> processing and *then* start processing any events it has outstanding.

This is exactly what I have proposed. All of gdb-events.sh's "events" can
act as either hooks or real, queued events. Right now I am using them as
hooks, but it has always been my plan to export those events into the Tk
event loop.

> In such a model, I don't think any (or very few) hooks are needed.
> Insight can find out the stop reason by asking GDB (just like MI did).
> All GDB needs to do is tell insight that the program state changed.

That is correct. I've been whacking all the hooks and inserting event
notifications.

I cannot find where mi asks for state information, could you point it out?
As far as I can tell, MI relies on some annotated output from
print_stop_reason.

I'll keep looking for the MI implementation of this...
Keith

Re: [RFC] Inferior stop events

[Elena Zannoni]

Hmmm, memory failing... aging process irreversible....
I seem to recall we did something for inferior events notification
Try looking at inferior_event_handler in inf-loop.c.

But yes, the reason for stopping is just spit out directly from
print_stop_reason.  Another thing to keep in mind is that MI was
designed from the start using an async remote target. That had
definitely an influence on how we did things. Remember the out-of-band
output category?

Elena


Keith Seitz writes:
 > On Thu, 14 Jun 2001, Andrew Cagney wrote:
 > 
 > > I think everyone agreed this was wrong long ago.  It should be:
 > >
 > >
 > > 	GDB Internals -> message -> Insight
 > > 	   |                           |
 > > 	   -------- Event Loop ---------
 > >
 > >
 > > That is, instead of Insight sitting on top of GDB processing stuff
 > > instantly, Insight would sit adjacent to GDB, allow GDB to complete its
 > > processing and *then* start processing any events it has outstanding.
 > 
 > This is exactly what I have proposed. All of gdb-events.sh's "events" can
 > act as either hooks or real, queued events. Right now I am using them as
 > hooks, but it has always been my plan to export those events into the Tk
 > event loop.
 > 
 > > In such a model, I don't think any (or very few) hooks are needed.
 > > Insight can find out the stop reason by asking GDB (just like MI did).
 > > All GDB needs to do is tell insight that the program state changed.
 > 
 > That is correct. I've been whacking all the hooks and inserting event
 > notifications.
 > 
 > I cannot find where mi asks for state information, could you point it out?
 > As far as I can tell, MI relies on some annotated output from
 > print_stop_reason.
 > 
 > I'll keep looking for the MI implementation of this...
 > Keith
 > 
 > 

Re: [RFC] Inferior stop events

[Keith Seitz]

On Fri, 15 Jun 2001, Elena Zannoni wrote:

>
> Hmmm, memory failing... aging process irreversible....
> I seem to recall we did something for inferior events notification
> Try looking at inferior_event_handler in inf-loop.c.

Ahhh... Two comments:

1) It doen't seem complete.
2) It's not an event source! It posts no events to the event queue...

Even if we could put some sort of event posting into
inferior_event_handler, we're STILL missing reasons for the stop, which
(was) already known by the time this function is called.

> But yes, the reason for stopping is just spit out directly from
> print_stop_reason.  Another thing to keep in mind is that MI was
> designed from the start using an async remote target. That had
> definitely an influence on how we did things. Remember the out-of-band
> output category?

I'm sorry, but I just don't see how this conflicts with what I've done.
IMO, gdb-events.sh and my proposed change is correct (or is at least
closer to being correct). What MI does (print_stop_reason modification) is
wrong. It does not generate an event, which is not hard to believe, given
that MI is really not event driven. It's just another command line with
different input/output syntaxes.

I guess I'm dense -- I do use a GUI for debugging, after all.
Keith

Re: [RFC] Inferior stop events

[Andrew Cagney]

> 2) It's not an event source! It posts no events to the event queue...
> 
> Even if we could put some sort of event posting into
> inferior_event_handler, we're STILL missing reasons for the stop, which
> (was) already known by the time this function is called.


For an async target, MI returns to the event-loop, at some later stage, 
GDB notifies MI that the target has stopped via the function 
mi_exec_async_cli_cmd_continuation() which was registered using 
add_continuation(). It is simply unfortunate that, for synchronous 
targets it uses another more nasty mechanism (fakeing asynchronous 
behavour).


> I'm sorry, but I just don't see how this conflicts with what I've done.
> IMO, gdb-events.sh and my proposed change is correct (or is at least
> closer to being correct). What MI does (print_stop_reason modification) is
> wrong. It does not generate an event, which is not hard to believe, given
> that MI is really not event driven. It's just another command line with
> different input/output syntaxes.


MI (ui-out, ui-filek, libgdb, event hooks, ...) is an architecture.  The 
top level happens to look like ``just another command line with 
different input/output syntaxes''.

Anyway, there is a far more important and underlying issue here. Insight 
needs to start putting some distance between its self and GDB - it can 
no longer assume certain GDB internals.  Knowing this needed to happen 
was one of the motivations behind the MI design.

With that in mind.  The only messages/events I'd expect GDB to send to 
clients are very simple vis:

	o	target busy
	o	target ready

longer term that might get expanded into:

	o	thread created/running/stopped/dead

The important thing is that GDB provides the absolute minimum of 
information and certainly not internal details.  The assumption is that 
the client will then, later, extract the details it needs from GDB using 
a ``libgdb/ui-out'' query.

As an example, look at the breakpoint interface.  The breakpoint events 
(created, changed, deleted) only include the breakpoint number.  It is 
assumed that the client will (when GDB is idle) extract the details 
using gdb_breakpoint_query() and a ui-out builder.

In the case of insight, it could use the above.  Alternativly, it could 
implement the more robust model:

   GDB                 event handler            insight
          -> stopped ->       |
          -> started ->       |
          -> stopped ->       |
                              |
     .-< stop-reason(uiout)? <'
     |
     `--> uiout = reason >----.
                              |
	                     `-> target-stop-event ->

The middle component (event hander) would, at it leasure, extract the 
stop reason from GDB and then pass it onto insight.

	Andrew