Re: [Various] obsoleting the annotate level 2 interface

[Jim Ingham <jingham at apple dot com>]

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 <nick@nick.uklinux.net>
> 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