RE: asynchronous MI output commands

[Alain Magloire <alain at qnx dot com>]

> From: Daniel Jacobowitz [mailto:drow@false.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.
>