This is the mail archive of the
mailing list for the GDB project.
Re: vast numbers of unimplemented MI commands.
- From: "Alain Magloire" <alain at qnx dot com>
- To: jingham at apple dot com (Jim Ingham)
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 19 Sep 2003 10:50:39 -0400 (EDT)
- Subject: Re: vast numbers of unimplemented MI commands.
[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
> salary!) .
> 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 our
> 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 the
> 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.
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 ?
> 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 to
> 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"
> ~"\nFile "
> ~"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.
> 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. We
> 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 ^running,
> for regularity it would probably be better to leave that out. But with
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 console".
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 that
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 signal ?
etc, etc ...
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 console-quoted".