From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19750 invoked by alias); 11 Aug 2004 00:51:15 -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 19682 invoked from network); 11 Aug 2004 00:51:14 -0000 Received: from unknown (216.254.0.206) by sourceware.org with QMTP; 11 Aug 2004 00:51:14 -0000 Received: (qmail 1828 invoked from network); 11 Aug 2004 00:51:14 -0000 Received: from dsl081-242-080.sfo1.dsl.speakeasy.net (HELO [192.168.1.112]) (gdb001@[64.81.242.80]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with RC4-SHA encrypted SMTP for ; 11 Aug 2004 00:51:13 -0000 In-Reply-To: <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com> References: <5956F1E2-EB0D-11D8-9949-000A9569836A@apple.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A54B4DA-EB30-11D8-9650-000A95DA1012@speakeasy.net> Content-Transfer-Encoding: 7bit Reply-To: gdb@sources.redhat.com From: Chris Friesen Subject: Re: GDB/XMI (XML Machine Interface) Date: Wed, 11 Aug 2004 00:51:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2004-08/txt/msg00159.txt.bz2 Hi Bob, I'm not defending MI, I just haven't had any problems parsing MI output, mi0 or mi1, using Apple's branch of gdb. The structure is well defined and if you parse the payload into arrays and dictionaries then it's not so bad to deal with. The versioning problem you mention is solved by having a specification for backward compatibility and not by any inherent virtue of XML. (We could just add a version field to MI output...FYI: Apple's branch has an MI verify command to test for support of MI commands.) So I'm not sure what XML delivers for MI other than people can use a 'standard' parser. I guess the DTD's are a nice place for the spec of the MI commands and there are tools to help validate against them, so that's a win. (The code is *not* the spec people...) > From: Bob Rossi > Date: August 10, 2004 1:14:40 PM PDT > To: gdb@sources.redhat.com > Subject: GDB/XMI (XML Machine Interface) > > 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 > > 1.2 The Objective > > The objective of GDB/XMI is to create a reliable protocol between > GDB and the front end controlling GDB. Is MI not reliable? Reliable is good. > > 2. The GDB/XMI Overview > > 2.1 Passing Information between GDB and the front end > > All information passed between GDB and the front end is done in > the form of an XML document. Each XMI command, generates an XML > document, and is sent from GDB to the front end. > This would not be good for MI commands *to* gdb as developers of MI commands often enter them by hand. > > 2.5 Version Management > > This model keeps front ends working with both old and new GDB's, > which > is unfortunately a task that most front ends have to and should deal > with. > I don't see a new IDE supporting an old GDB, it might with minimum version numbers for the MI commands, but the new IDE isn't going to support a deprecated command if they choose to use the new MI command. The IDE is going to choose features over using an old version of GDB. Backward compatibility of MI commands will make it so my old IDE can use a new GDB, which is more important. > 3.3.2 GDB/MI Output > > (gdb) > -stack-list-frames > > ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func",file= > "test.c",line="13"},frame={level="1",addr="0x080484f5",func="main",file > ="test.c",line="54"}] > > ^done,stack=[frame={level="0",addr="0x080483ef",func="short_func", > file="test.c",line="13"},frame={level="1",addr="0x080484f5", > func="main",file="test.c",line="54"}] > > 3.3.3 The GDB/XMI Output > > > > > 0 > 0x080483ef > short_func > test.c > 13 > > > 1 > 0x080484f5 > main > test.c > 54 > > > Hate to say this but the MI output is more human readable for 'key' and 'value' (good for debugging) while the the XML is not friendly to my scanning... the MI reads more like code. If you look at it, the MI has the same tree structure as the XML, just written in a less pedantic form. An MI to XML formatter/converter wouldn't be that hard. Overall MI suffers most from not having a specification for the various commands, as well as not documenting which platforms the commands are supported on. I don't see a big benefit from using XML. It could be tested by writing a simple MI to XML converter without having to make a lot of changes to gdb. Cheers, -ChrisF