From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3075 invoked by alias); 19 Aug 2004 23:49:23 -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 3068 invoked from network); 19 Aug 2004 23:49:21 -0000 Received: from unknown (HELO lakermmtao06.cox.net) (68.230.240.33) by sourceware.org with SMTP; 19 Aug 2004 23:49:21 -0000 Received: from white ([68.9.64.121]) by lakermmtao06.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040819234920.KXLR4710.lakermmtao06.cox.net@white> for ; Thu, 19 Aug 2004 19:49:20 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Bxwen-0001IH-00 for ; Thu, 19 Aug 2004 19:49:21 -0400 Date: Thu, 19 Aug 2004 23:49:00 -0000 From: Bob Rossi To: gdb@sources.redhat.com Subject: Re: GDB/XMI (XML Machine Interface) Message-ID: <20040819234921.GA4966@white> Mail-Followup-To: gdb@sources.redhat.com References: <20040810201440.GA24186@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040810201440.GA24186@white> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-08/txt/msg00243.txt.bz2 On Tue, Aug 10, 2004 at 04:14:40PM -0400, Bob Rossi wrote: > Hi, > > As most of you know, I have been writing a front end to GDB called CGDB. > However, for a while now, I have been a little disappointed with the MI > interface. In my RFC I have described the problems I have with MI and I > have proposed a new method of communication between GDB and the front > end. > > If there is good feedback on this RFC, I will continue research on it, > filling in details that I thought would be best to wait until after an > initial acceptance. > > If the RFC is accepted by the community I plan on implementing an > initial version of the XMI interface in GDB, and programming CGDB to > sit on top of GDB. This will at least give the community one open > source front end to GDB and an example to prove that the new > machine interface works. > > I can't wait to hear your opinions/comments. Hi, Well, it seems as if my efforts only brought up enough interest to just get a couple of replies. Basically, most of you point out that I am interested in changing at a high level the development process of the interface between GDB and the front end. Obviously, switching GDB's output to XML only gains the front ends a simple way to parse the data. Besides validation, and maybe transformations, it basically does nothing else. I have listed some other higher level things, like Michael pointed out. These are the things that I feel will make my front end successful over the long run. I understand that what makes my front end successful might not make everyone's successful, but the union of all these ideas will make everyone's front end successful. Therefor, I am offering up at least the minimum amount of work that needs to be done to GDB in order to make a front end successful, not just now, but in the future also. Michael noted some of the things I think a protocol should contain . The MI has an insufficient reflective interface. . MI output changes from time to time. Your proposal is to restrict the changes: fields can be added but not removed or modified; commands can be added and old commands deprecated. . Inferior process output mixes with gdb output. All of these issues are key to what I think a front end should expect from GDB. However, I realize that none of these issues have anything to do with XML. XML is just an obvious way to communicate data between to entities. Jim suggested, 1) You can run gdb and use the tty command to send inferior output to a separate pty. 2) The XML output should just be another ui_out. and some suggestions on commands sent from the front end to GDB. Nick G suggested, Now for the real honesty: I don't think an XML interface is going to fix the real problem. The real problem is that GDB is not a library. Chris F suggested, He defiantly didn't see the benefit to switching to XMI, since XML is harder for him to understand than MI output. I don't really know where to go from here. The XML change I think is a no brainer. It is a task that every front end writer in the future will be thankful for. Believe me, no one is interested in parsing the MI output. It is a *complete waste of time*. Next and more importantly, the versioning is a major hurdle for me in regards to MI. I think protocols should always be backwards compatible, it is a necessity for the client of the protocol. However, up till now I might be the only one making a big stink out of this, and therefor the versions are not backwards compatible. I believe CVS snapshots and major releases should always adhere to the backwards compatibility test. For example, I use CGDB with a version of GNAT's GDB and it works because A2 hasn't changed. I want to be able to use XMI with a 4 year old GDB, because the software world is majorly screwed up, and sometimes I find myself having to work with ancient software. If this document could be modified in any way, I would be more than glad to make an initial effort at getting GDB/XMI going. I believe that all of the infrastructure for the MI commands can stay in place, and like Jim said, a new ui_out could be created. A re-write from the MI is the worst idea in my opinion. I think that GDB is finally maturing a protocol that front end developers can not snicker at. I believe it should just be modified in some ways and that XML would be a great plus for outputting data. Finally, the difference between a text based protocol and a libgdb interface is irrelevant to me. I would personally prefer the text based protocol at this point in time seeing that there is no libgdb. What stopped the production of that effort? Also, making clients link to the GDB they want to work with seems like a pain. My proposal would be to make all of the infrastructure change to the MI code, not new code. Add validation, versioning, and maybe a new way besides the tty command to separate GDB output and the inferior output. Finally, add a new ui_out that outputs the commands in XML. Thus, only adding the XML feature completely, otherwise, changing the process's of the MI to work the way I am suggesting. Eagerly awaiting instructions :) Thanks, Bob Rossi