This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: asynchronous MI output commands
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