Re: GDB/XMI (XML Machine Interface)

[Chris Friesen <gdb001@speakeasy.net>]

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 <bob@brasko.net>
> 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
>
>   <?xml version="1.0"?>
>   <stack>
>     <frame>
>       <level>0</level>
>       <addr>0x080483ef</addr>
>       <func>short_func</func>
>       <file>test.c</file>
>       <line>13</line>
>     </frame>
>     <frame>
>       <level>1</level>
>       <addr>0x080484f5</addr>
>       <func>main</func>
>       <file>test.c</file>
>       <line>54</line>
>     </frame>
>   </stack>
>

<snip>

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