From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6770 invoked by alias); 1 Feb 2003 00:43:33 -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 6760 invoked from network); 1 Feb 2003 00:43:33 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by 172.16.49.205 with SMTP; 1 Feb 2003 00:43:33 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h110hWI29928 for ; Fri, 31 Jan 2003 16:43:32 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 31 Jan 2003 16:43:32 -0800 Received: from apple.com (inghji.apple.com [17.201.22.240]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h110hWf08034 for ; Fri, 31 Jan 2003 16:43:32 -0800 (PST) Date: Sat, 01 Feb 2003 00:43:00 -0000 Subject: Re: [Various] obsoleting the annotate level 2 interface Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jim Ingham To: gdb@sources.redhat.com Content-Transfer-Encoding: 7bit In-Reply-To: <1044050405.3227.ezmlm@sources.redhat.com> Message-Id: <4DB45B30-357E-11D7-B17A-00039379E320@apple.com> X-SW-Source: 2003-02/txt/msg00000.txt.bz2 Nick, I don't think you need to be so worried. We have been able to get pretty far without these. Most of them are actually not very helpful. See comments below... On Friday, January 31, 2003, at 02:00 PM, gdb-digest-help@sources.redhat.com wrote: > From: Nick Roberts > Date: Fri Jan 31, 2003 12:11:07 PM US/Pacific > To: gdb@sources.redhat.com > Subject: Re: [Various] obsoleting the annotate level 2 interface > > >> On Wed, 29 Jan 2003 10:56:02 -0500, Christopher Faylor wrote: >>> On Wed, Jan 29, 2003 at 04:51:06PM +0100, Arnaud Charlet wrote: >>>> Honestly? No. MI has `kick ass' features sufficent to justify the >>>> move now: > >>> Well fine, so we are in disagreement. Maybe the gdb GUI you've >>> written >>> does not have the same requirements than GVD has. > >>> I'm not saying MI does not have some added value compared to CLI, I'm >>> just saying (and I'm not the only one) that there are some missing >>> features in MI which are important enough to be taken into account. > >> And the missing features are...? > > Well, the current online documentation at, > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC217, > says (summarised) : > > Also note that the commands with a non-available example (N.A.) are > not yet > implemented. > > -display-delete N.A. > -display-disable N.A. > -display-enable N.A. > -display-insert N.A. > -display-list N.A. A programmatic interface to gdb would just query the things it is interested in when it gets the stop message. If you want these displayed in the console, the user can use the command-line display command. So I am not even sure why these are here, probably an overzealous sense of completeness? > -exec-abort N.A. When things go bad, we always end up having to kill gdb, otherwise, the user usually kills the inferior themselves, or restarts it, which achieves this anyway. So we haven't needed this. > -exec-show-arguments N.A. PB - at least - always provides the arguments to gdb, so I am not sure why this are needed. > -file-list-exec-sections N.A. > -file-list-exec-source-files N.A. > -file-list-shared-libraries N.A. > -file-list-symbol-files N.A. We did need a shared library info command, though we actually cooked up one of our own because we have to play lots of games to limit the amount of grubbing around in shared libraries that gdb does (an average MacOS X program has 40 or 50 dependent libraries, and many of them - especially the ObjC ones - have lots of external symbols...) So we needed some slightly gnarlier commands. But I doubt the emacs mode has a special-purpose shared library info pane, so listing these in the console is probably good enough. > -stack-info-frame N.A. > -symbol-info-address N.A. > -symbol-info-file N.A. > -symbol-info-function N.A. > -symbol-info-line N.A. > -symbol-info-symbol N.A. > -symbol-list-functions N.A. > -symbol-list-types N.A. > -symbol-list-variables N.A. > -symbol-locate N.A. > -symbol-type N.A. A lot of these are unnecessary if you are using the varobj system. We do stack displays, locals, and expressions window without them. We haven't done a "view memory at the location of this symbol" but even then we wouldn't need -symbol-info-address, since we already have the varobj for the symbol, which has its address... > -target-attach N.A. > -target-compare-sections N.A. > -target-exec-status N.A. > -target-list-available-targets N.A. > -target-list-current-targets N.A. > -target-list-parameters N.A. Can't comment on these, we only do native debugging. > -thread-info N.A. > -thread-list-all-threads N.A. You can do everything you need for threads with the thread-list-ids and thread-select. If you had a thread package that supported some native thread info like named threads or whatever then -thread-info would be useful. Mac OS X doesn't do this, dunno if Linux does... But this is definitely a second order thing. We really have been able to get pretty far with the MI as it stands (plus the stuff that Andrew has so kindly offered to finish merging in.) It is much more pleasant than trying to parse gdb output, which is what the old PB used to do. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer