From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13486 invoked by alias); 29 Jan 2003 01:41:54 -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 13479 invoked from network); 29 Jan 2003 01:41:52 -0000 Received: from unknown (HELO nick.uklinux.net) (194.247.48.128) by 172.16.49.205 with SMTP; 29 Jan 2003 01:41:52 -0000 Received: by nick.uklinux.net (Postfix, from userid 501) id 131E276037; Wed, 29 Jan 2003 01:38:14 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15927.12416.601404.240113@nick.uklinux.net> Date: Wed, 29 Jan 2003 01:41:00 -0000 To: Jim Blandy Cc: rms@gnu.org, gdb@sources.redhat.com Subject: Re: obsoleting the annotate level 2 interface In-Reply-To: References: <15917.39229.935851.920452@nick.uklinux.net> X-SW-Source: 2003-01/txt/msg00470.txt.bz2 > 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