From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7383 invoked by alias); 19 Sep 2003 14:50:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7369 invoked from network); 19 Sep 2003 14:50:39 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 19 Sep 2003 14:50:39 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id KAA14716 for ; Fri, 19 Sep 2003 10:49:15 -0400 Received: (from alain@localhost) by smtp.ott.qnx.com (8.8.8/8.6.12) with UUCP id KAA22722 for gdb@sources.redhat.com; Fri, 19 Sep 2003 10:50:39 -0400 Message-Id: <200309191450.KAA22722@smtp.ott.qnx.com> Subject: Re: vast numbers of unimplemented MI commands. To: jingham@apple.com (Jim Ingham) Date: Fri, 19 Sep 2003 14:50:00 -0000 From: "Alain Magloire" Cc: gdb@sources.redhat.com In-Reply-To: <03BA45C6-E9FB-11D7-A429-00039379E320@apple.com> from "Jim Ingham" at Sep 18, 2003 10:10:33 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00237.txt.bz2 [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".