Re: asynchronous MI output commands

[Jim Ingham <jingham at apple dot com>]

On May 11, 2006, at 10:03 AM, Bob Rossi wrote:

> 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.
>
> Hi Jim,
>
> Well, I agree that this is a bug in the interpreter-exec command.
> I think both of your solution are appropriate. I would find it
> interesting to know which solution is easier to implement in GDB. The
> interesting case of course is when the user does a single CLI command
> that is a 'commands' definition. Thus, a single -interpreter-exec
> command can be similar to running N CLI commands.

We seem to get it half right for defined commands.  For instance:

(gdb) list main
1       int main (int argc, char **argv)
2       {
3
4         printf ("I got %d arguments\n", argc);
5
6         return 0;
7       }
(gdb) break 4
Breakpoint 1 at 0x2cdc: file main.c, line 4.
(gdb) break 6
Breakpoint 2 at 0x2cec: file main.c, line 6.
(gdb) define printAndContinue
Type commands for definition of "printandcontinue".
End with a line saying just "end".
>print argc
>continue
>end
(gdb) run
Starting program: /private/tmp/a.out
Reading symbols for shared libraries . done

Breakpoint 1, main (argc=1, argv=0xbffff404) at main.c:4
4         printf ("I got %d arguments\n", argc);
(gdb) set interpreter mi
-interpreter-exec console-quoted printAndContinue
~"$1 = 1"
~"\n"
^continuing
I got 1 arguments
~"\nBreakpoint "
~"2, main (argc=1, argv=0xbffff404) at main.c:6\n"
~"6\t  return 0;\n"
^done,MI_HOOK_RESULT= 
{HOOK_TYPE="frame_changed",frame="0"},MI_HOOK_RESULT= 
{HOOK_TYPE="stack_changed"}

Normally the "I got 1 arguments" line would go to the tty for the  
target, so that wouldn't show up in the output that the MI client  
would be parsing.

What we do here is emit the "^continuing" so the MI can know that the  
target started.  This might more properly be an "=running" or  
something like that.  I think this is just an artifact of how the mi  
works right now.

Then when the defined command stops, we tell the MI what has changed  
in these HOOK_RESULT output messages.  Again, it's arguable that  
these should also be "=" type messages.  When I started working on  
this Xcode (ProjectBuilder as it then was) was not good at handling  
the "=" type asynchronous messages, and I haven't gotten around to  
changing this.

You don't get a *stopped message because the continuation is buried  
in the defined command.  We could fix this, and if the target has run  
tell the client that it has indeed stopped.  But this may also be an  
argument that it's better to tell the client about this through the  
asynchronous "=" messages, especially since the define command could  
run a number of times, and end up with a command that doesn't run the  
target.

Anyway, what we have now works well enough, if a little irregular,  
and I don't think fixing it up to be nicer looking would be  
particularly hard to do.

Note that breakpoint commands can also be a problem here, since they  
can run console commands out from under the MI.  They can in fact  
cause the target to stop, print some stuff, then continue again.  So  
if you allow this - which we had a lot of pressure to do since  
breakpoint commands are pretty handy - you have to do a little  
fiddling to get that right as well.

Jim

> I haven't even tested this case out yet, but I'm assuming there's big
> problems in this area. I seem to have more time lately, and would like
> to start patching up some of these holes. I would very much like to  
> see
> mi3 come out soon, with a lot of these problems resolved.
>
> Thanks,
> Bob Rossi