Re: vast numbers of unimplemented MI commands.

["Alain Magloire" <alain at qnx dot com>]

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