asynchronous MI output commands

> From: Daniel Jacobowitz [mailto:drowfalse.org]
> 
> On Thu, May 11, 2006 at 08:42:03AM -0700, Jim Ingham
wrote:
> > I think that the lack of notification about what
has gone on when
> > somebody uses interpreter-exec to run the target
is just a bug in the
> > interpreter-exec command.  Since that command
allows lots of stuff to
> > go on behind the MI client's back, you need to
inform the client
> > about this.  You could either post asynchronous
notifications about
> > what happened (for instance an =running or
whatever) or you can just
> > make the -interpreter-exec command behave like
-exec-next when it
> > does indeed run the target.  The latter is what we
did for Xcode, so
> > you get the *stopped message if the target was
run.
> 
> This is a topic I'd like to see a single consensus on,
sometime soon.
> I have an ulterior motive.
> 
> I wrote, some time ago, patches to use Guile to
implement GDB CLI
> commands.  It works by, roughly, opening a
bidirectional MI channel to
> Guile, and temporarily suspending the CLI channel.  But
if the front
> end in use is MI, what notifications should that
frontend get?  Should
> it be told the target is running, even if e.g. the user
defined command
> just calls a function in the target?  Should the Guile
interpreter get
> notifications when the user or MI client does
something?
> 

IMHO, the MI interpreter should get a notification when the
target changes
state from a side effect of CLI commands.  So the example,
when the "runs"
command is executed (next, step, call, finish, signal
etc...) an OOB should
be drop:
 ^running

Or for example if an external application drops a SIGINT on
the inferior, I
do expect a notification. 
 *stopped,...

The GDB CLI channel probably does not need notification
because the protocol
was not meant for this but rather a direct access by the
users to gdb
commands, strictly query/answers.

> Basically, I think that getting this right requires
multiple
> interpreters live at the same time.
> 

Is there really a case for this?  The scenario I see is
within one
interpreter (say MI), you want to give more power to the
users and let them
access advanced gdb commands, so the interpreter-exec
provides this nicely.
The only problems is the side effects.  Notification does
not have to be
complex, for example something like:
=state_change

Notification, could tell the front end to reload the
settings (the
breakpoints, the watchpoints, dlls, etc ...)

> I'd like to come back to that code someday.  And,
preferably, merge
> Perl and Python support also.  Kip Macy posted Perl
bindings and the
> Python ones would be easy to write, now that I know
Python - in fact
> it's the only one out of the three I'd be comfortable
doing myself,
> the Guile bits were very skeletal.
>