Re: vast numbers of unimplemented MI commands.

[Jim Ingham <jingham@apple.com>]

Alain,

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:

http://developer.apple.com/tools/xcode/index.html

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

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.
>>
>
> 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",sta 
>> rt
>> ="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  ...

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                                   jingham@apple.com
Developer Tools
Apple Computer