This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: obsoleting the annotate level 2 interface
- From: Nick Roberts <nick at nick dot uklinux dot net>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: rms at gnu dot org, gdb at sources dot redhat dot com
- Date: Wed, 29 Jan 2003 01:38:08 +0000
- Subject: Re: obsoleting the annotate level 2 interface
- References: <vt265sjj6vi.fsf@zenia.red-bean.com><15917.39229.935851.920452@nick.uklinux.net><vt27kcprojq.fsf@zenia.red-bean.com>
> Nick, what is involved in bringing gdb-ui over to using MI?
A dialogue is a good starting point. I'm slightly surprised at the
lack of communication between GDB and Emacs developers given the common
heritage.
I think writing a mode for Emacs that uses MI would require quite a different
approach to gdb-ui.el. Think of what was involved in `bringing GDB over to MI'
(a lot of work, I would imagine).
> Annotations have been deprecated for a while now, so it probably won't
> kill us to keep them for a while longer, but it doesn't make sense for
> us to keep them indefinitely; gdb-ui needs to start making the
> transition.
I think this is what has baffled a lot of GDB users. There are something like
39 problem reports open for MI and only 14 closed (I'm hesitant to say this as
I applaud the transparency of the system and I don't want to encourage
secrecy). We don't see how the GDB developers can deprecate annotations or
encourage users to switch to MI until it is ready.
For my part, I will start to look at MI again. It appears that it has undergone
a lot of development since I looked at it last year. GDB developers could
help this process (not just for me, but all users) by ensuring that the
documentation for MI is bang up to date.
> But from what I
> do understand, I really think MI is the way GDB should go.
I think everyone accepts this. It is just the timing that is being questioned.
> Personally, I want a command-line interface to GDB too; I'd like to
> see MI used to improve that (say, by handling 'display' or the
> breakpoint list better), but I don't want to replace it. What is MI
> missing in this regard? It seems to me like it's all there:
>
> zenia:emacs$ $D6/gdb/gdb --interpreter=mi2 $D6/gdb/gdb
> ~"GNU gdb 2003-01-23-cvs\n"
> ...
I've only looked at GDB 5.0 (GNU gdb 20010813 (MI_OUT)). It doesn't seem to
have mi2. I didn't spend much time looking at MI, I'm just one person,
dabbling in my spare time. I saw that annotations did what I wanted and I ran
with it. I don't think that I could have taken MI as far with such limited
resources.
> What are the other issues?
At the time, streams didn't seem to work. I couldn't seem to generate the @
prefix output. That's probably changed now. I can't really say much more
until I have something concrete to experiment with.
> This may not be the largest issue, but one thing that might be of
> interest is that, given the way the MI support is done, it would be
> very easy to have GDB provide all its output as Emacs Lisp
> s-expressions, so Emacs could just 'read' them directly. And this
> would be a modular and relatively small change. All you need to do is
> provide your own `struct ui_out_impl' that prints things the way you
> like.
I don't know what form it should take but I do think that GDB should hook into
Emacs in some way and that they appear to have drifted apart.
I have never seen the source for GDB. Perhaps you can explain why annotations
is difficult to maintain. In my limited experience, I have found that two
features in a program can often be orthogonal to one another. That is, one
feature can be developed as if the other feature isn't there.
Also gdb-ui.el probably doesn't need all the annotations. If you lost some key
ones (frames-invalid and breakpoints-invalid, for example) would this make it
easier to maintain?
Nick