This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: asynchronous MI output commands
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.
Jim
On May 11, 2006, at 8:02 AM, Bob Rossi wrote:
I agree, the example that comes to my mind is "next", "step",
"finish",
"continue" etc ... To do some optimization front-ends will
probably
need to
know the last command issue (for example clearing all the
variable state
in
a variable view for "continue").
I see the point, however, how do you know if the user typed
continue? I
allow the user to have access to the console, and by doing so, I
can't
make any assumptions on what GDB is doing.
I suppose you could intercept the CLI commands before sending it
to GDB
This isn't a good idea, and probably impossible. Don't forget about
user
defined commands. Also, don't forget that hitting a breakpoint can run
some commands. You never really know when 'continue' is sent.