Re: RFC: MI output during program execution

Jim Ingham
2005-08-08T17:09:38Z

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
>