This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: vast numbers of unimplemented MI commands.


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
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.

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 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"
^done,time={wallclock="1.83584",user="1.02000",system="0.11000",start= "1

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. We
tarted this up a bit on our end, so you get:

-interpreter-exec console-quoted next
*stopped,time={wallclock="0.01305",user="0.00000",system="0.02000",sta rt

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 ...

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 console-quoted".

Jim -- Jim Ingham Developer Tools Apple Computer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]