Re: asynchronous MI output commands

[Daniel Jacobowitz <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?

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

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.

-- 
Daniel Jacobowitz
CodeSourcery