This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Various] obsoleting the annotate level 2 interface


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, wrote:

From: Nick Roberts <>
Date: Fri Jan 31, 2003  12:11:07  PM US/Pacific
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,,
says (summarised) :

Also note that the commands with a non-available example (N.A.) are not yet

-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 Ingham
Developer Tools
Apple Computer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]