This is the mail archive of the
gdb@sources.redhat.com
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
> like:
>
> -interpreter-exec console-quoted "info func"
> ~"All defined functions:\n"
> ~"\nFile "
> ~"/SourceCache/Csu/Csu-46/crt.c:\n"
> ~"void _start(int, char **, char **);\n"
> ~"static void _call_mod_init_funcs(void);\n"
> ...
> ^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start="1
> 063903591.475599",end="1063903593.311440"}
> (gdb)
>
>
> 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.
>
8-)
>
[...]
> 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
> ^stepping
> ^running
> (gdb)
> *stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",start
> ="1063903739.568366",end="1063903739.581413"},reason="end-stepping-
> range",thread-id="1"
>
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
> achievable.
>
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".