This is the mail archive of the
mailing list for the GDB project.
Re: vast numbers of unimplemented MI commands.
- From: Jim Ingham <jingham at apple dot com>
- To: Alain Magloire <alain at qnx dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 19 Sep 2003 10:44:30 -0700
- Subject: Re: vast numbers of unimplemented MI commands.
- References: <200309191450.KAA18645@smtp.ott.qnx.com>
On Sep 19, 2003, at 7:50 AM, Alain Magloire wrote:
[some lines deleted]
I don't think that is right. You could always issue console commands
straight to the mi, THAT is the real way to cheat (and I agree that
should be closed off). The console interpreter (and -interpreter-exec
console) fulfills a very useful purpose: satisfying folks who like a
console interface to gdb as well as the GUI. We would probably get
assassinated right quick if we were to try to take this out of Xcode
(used to be Project Builder - another Marketing person earns their
Note that we have had to fix up a few things in the MI as we have gone
along with Xcode, and most of those fixes are in the Apple sources not
in the main FSF repository. We are short-staffed for what we need to
And for the fixes ... thank you !!!
do here, which sort of explains why we haven't gotten to submitting
sources back to the FSF - experience has shown that to be very time
consuming. But you can get the Apple sources from the Apple Darwin
site, or from the opendarwin site. If you are serious about using the
MI it might be worth your while to have a look here, since Xcode is
only fairly mature GUI the uses the MI...
I disagree 8-).
There are a few that uses MI and do a good job at it.
I don't mean to disparage any of the other projects that use MI. When
we converted PB to MI three years ago, we really were the only users
(the project for which it was invented having perished ignominiously
before I left RedHat...)
This is not saying Xcode is not a great product of course 8-)
I do not have a Mac to try it, but any URL handy with good snapshots?
or just docs on Xcode ?
The developer pages are at:
The debugger is by no means done, and we have been focusing more on
high-level language features. So for instance, we don't yet support
Memory views, etc (which I am sure are more important to you at qnx...)
But some things like the variable formatters are pretty neat (and took
a lot of work to make work reliably...)
I don't understand this comment. This is exactly what
-interpreter-exec console is for. If the user issues this sort of
console command, you just echo back whatever it sends to your console
window. You can also annotate if they do anything of other interest
the GUI (proceeding the inferior, setting breakpoints, etc...) Note
that to make parsing the output from gdb, I added a "console-quoted"
interpreter that sends stuff back in the cli pretty-printing, but the
output strings are packaged up in MI format. So you get something
-interpreter-exec console-quoted "info func"
~"All defined functions:\n"
~"void _start(int, char **, char **);\n"
~"static void _call_mod_init_funcs(void);\n"
This means that if the response from a command happens to start with
^done or something like that, you won't get confused...
Yes this is the answer to our prayers.
"-interpreter-exec console" does not do anything for us since we
can not use it to sync the UI from the user input.
However "-interpreter-exec console-quoted", at least, how you
describe it is what we want.
One other thing to note is that the gdb Mac OS X native target is a
true asychronous target - we run the ptrace waits in a separate thread
(and the Mach exceptions handler, you really don't want to know...) so
the event loop is always live. This means that when the target is
running, the GUI can ask gdb what it's state is (we made a -exec-status
command for this) and get back "running" or "stopped". So whenever it
gets really confused, it can just do this. Getting the async target to
work was a royal pain in the neck, and there are still some residual
problems, but for this purpose it is really handy!
I still have some cleanup to do on this, because there are various
places (like the show command) where the command ignores the uiout and
prints straight to gdbstdout (grrr....) But this makes it pretty easy
to handle this sort of thing.
This is just a hole in the interpreter-exec console implementation.
tarted this up a bit on our end, so you get:
-interpreter-exec console-quoted next
Yes, Yes , Yes !
Now __This__ is usefull.
I forget why the GUI guys wanted the ^stepping as well as the
for regularity it would probably be better to leave that out. But
I can guess:
^stepping and ^running are vital for the IDE to maintain its state
without them "console-quoted" is as useless as "-interpreter-exec
There is a difference between "next" and "continue"(for the IDE) and
the ^running is if the next statement is blocking, the IDE will know
it is running.
this modification, it is very easy to keep the GUI in sync with the
CLI. The Xcode console interpreter actually works pretty well, and
very seldom gets out of sync with the GUI.
In any case ... very nice improvements.
This has not been our experience. Xcode doesn't use any CLI commands,
provided you don't consider "-interpreter-exec" a console command. It
took some work on our part to get this all going, but it is very
Well then how do you deal with shared libraries ? How do you do
deferred breakpoints? how do you load a shared library symbol ?
How do you get the signal handlers? How do you set the handle for a
etc, etc ...
For shared libraries we added the "future-break" command which will
keep trying to set a breakpoint till it takes. We actually tried to
submit that a while ago, but there was no consensus whether this should
be a separate command, the default behavior of break, or what. We got
distracted by some emergency, and this went no further.
We also send asychronous notifications of shared library loads so the
GUI can present a table of the loaded shlibs.
We haven't had requests for a GUI for signal handling yet, when we do
we will have to implement something...
There are currently no MI counterparts ... at least in the FSF version.
And the console prompt is a problem that "-interpreter-exec console"
does not solve, .. but looking forward for "-interpreter-exec
Jim Ingham firstname.lastname@example.org