Re: RFC: MI output during program execution

[Jim Ingham <jingham at apple dot com>]

First off, "console-quoted" has a less grand  purpose than Nick  
thinks...  I added "console-quoted", because in the version of the  
interpreter code that I maintain in the Apple sources the console  
interpreter really is the CLI console interpreter, regardless of  
whether you are running it from the MI or not.  That is because I  
wanted to be able to really switch interpreters, not just fake the  
CLI under the covers of the MI - which is what Keith & Elena's  
version of the interpreter code does.  But this means that for the  
"console" interpreter, you get raw console output, not quoted nicely  
for consumption by the GUI.  So we needed a version of console to run  
from the MI that did the nice quoting.  Other than that, "console"  
and "console-quoted" are identical.

About Nick's patch.  We achieve the same result, but with a different  
method.  What I do is whenever I run a CLI command with the  
mi_cmd_interpreter_exec,  I install a bunch of notify hooks - the  
code to look at is mi_insert_notify_hooks.  These give us a way to  
funnel notifications from "behind the CLI's back".

We get a bunch of notifications this way, including breakpoint set,  
frame changed, etc...  Right now, I think most of the hook stuff got  
ripped out of the FSF gdb in favor of events^H^H^H^H^H^Hobservers.   
Someday when I have some spare time I need to go look at the  
observers, and see if I can get them to do the same thing I need the  
hooks to do.  One of the weaknesses of the hooks is they don't store  
data so I have to squirrel the mi interpreter the hook is for off  
into a global - which is unclean.  Maybe this sort of thing will be  
better if the hooking method is more advanced.

Anyway, this model is a sort of "on demand" way of implementing  
Daniel's notion of "keeping all the interpreters open at the same  
time".  Namely, when interpreter A relinquishes control to  
interpreter B, it registers for all the things it would like to be  
informed of before it does so.  It has the virtue of not having to  
multiplex all the information gdb generates down multiple channels.   
You just selectively funnel off the pieces you are interested in.  As  
long as the hooks (or whatever they are now with observers...) are  
correctly maintained, this is pretty easy to make work.

In general, there's only one interpreter "in charge" at a time.  So I  
think this model of "inserting your listeners when you give up  
charge" is not too bad.  It has proved pretty workable for what we  
do, anyway.  And I like it better than Nick's method of mocking up  
certain commands in interpreter-exec.  It seems better to specify  
"what you want to be told about" when one interpreter invokes  
another, rather than trying to guess which commands might do  
something you might want to know about.  Unless you disallow "define"  
on the CLI side, you're always going to lose this game anyway...

Note, there are some tricky bits to this model.  For instance, if you  
are running the MI, and use "-interpreter-exec console" to set  
commands on a breakpoint, those commands should be run with the CLI  
interpreter when you hit the breakpoint.  But that means that some  
actions - in this case hitting a breakpoint as part of the completion  
to an "-exec-run" command - can force you over to the CLI interpreter  
for a little while.

There's a bit of trickery in our sources to handle this.  I didn't do  
it "right" - where "right" would be to abstract the notion of a  
breakpoint command out of the CLI and do some hand-off between the  
current interpreter and the one in charge of the breakpoint command  
code.  For our purposes, the CLI is the only thing that gets to  
register breakpoint commands - the GUI can react in a scripted manner  
to breakpoint hits on its own, so there was no need to add this  
complexity.

The most current version of our sources is available in tar.gz form at:

http://www.opensource.apple.com/darwinsource/tarballs/other/ 
gdb-384.tar.gz

I am pretty sure the CVS repository is up to date with this as well  
(some projects require an ADC membership, but gdb & friends have  
anonymous access).  See

http://developer.apple.com/darwin/tools/cvs/howto.html

for more details.

This code is based on a merge that's almost a year old now.  Stan &  
Klee are working away at a more recent merge - we're pretty sure the  
patient will survive, but it's definitely not ambulatory yet...

Jim








On Aug 8, 2005, at 6:05 AM, Daniel Jacobowitz wrote:

> On Mon, Aug 08, 2005 at 04:20:43PM +1200, Nick Roberts wrote:
>
> > Although Emacs will increasingly use GDB/MI to interact with GDB,  
> > the GUD
> > buffer will always require the use of CLI commands.  These are  
> > executed via
> > "-interpreter-exec console" that Jim Ingham/Apple contributed.  In  
> > general
> > this isn't a problem, but CLI commands which start the inferior  
> > e.g run, next,
> > finish etc do not tell Emacs when the inferior is executing (do  
> > not output
> > ^running) and in some cases generate inappropriate output such as  
> > the current
> > source line as CLI output.  I would like to change the output of  
> > these
> > commands to that of their MI counterparts.  I think that Apple  
> > have added a
> > separate interpreter (console-quoted) for this kind of thing.  The  
> > patch below
> > reflects my more modest resources and limited knowledge and seems  
> > to do the
> > kind of thing that Emacs needs.  It doesn't change direct use of  
> > MI commands,
> > just the behaviour of a subset of CLI commands invoked the the MI  
> > interpreter:
>
> Fortunately, we've got access to all these bright folks at Apple.
> Does the console-quoted approach sound good to you?  Jim, is a recent
> snapshot of the code for it available?
>
> The following has no frontend implementation experience behind it
> whatsoever.  However, it's relevant from my few tries at adding full
> scripting support to GDB.  What I'd like to see is a way to keep
> multiple interpreters open at the same time.  Then, have one of them
> accepting input at a time, and receiving informative output, but  
> all of
> them receiving some kinds of output.  For instance, all open MI
> channels could receive a notice on breakpoint deletion, no matter  
> where
> the request came from.  If the console starts GDB running in this  
> case,
> the MI interpreter would still get a ^running.
>
> --
> Daniel Jacobowitz
> CodeSourcery, LLC