Re: GDB/XMI (XML Machine Interface)

Chris Friesen
2004-08-11T00:51:15Z

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>
>
> <level>0</level>
> <addr>0x080483ef</addr>
> <func>short_func</func>
> <file>test.c</file>
> <line>13</line>
>
>
> <level>1</level>
> <addr>0x080484f5</addr>
> <func>main</func>
> <file>test.c</file>
> <line>54</line>
>
> </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