This is the mail archive of the
mailing list for the GDB project.
Re: [Various] obsoleting the annotate level 2 interface
- From: Jim Ingham <jingham at apple dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 31 Jan 2003 16:44:21 -0800
- Subject: 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,
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?
From: Nick Roberts <email@example.com>
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
Well fine, so we are in disagreement. Maybe the gdb GUI you've
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.
Well, the current online documentation at,
And the missing features are...?
says (summarised) :
Also note that the commands with a non-available example (N.A.) are
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.
PB - at least - always provides the arguments to gdb, so I am not sure
why this are needed.
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.
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...
Can't comment on these, we only do native debugging.
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 firstname.lastname@example.org