This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB frontends, MI-speak and object notation
- From: Dmitry Dzhus <dima at sphinx dot net dot ru>
- To: gdb at sources dot redhat dot com
- Date: Sat, 30 May 2009 20:42:46 +0400
- Subject: Re: GDB frontends, MI-speak and object notation
- References: <87d49tv3z2.fsf@sphinx.net.ru>
I've managed to map MI output to structured data using JSON parser from
Emacs. I needed to wrap the whole GDB/MI answer in curly braces, wrap
Âfield names in double quotes, and change equal signs in the
`VARIABLE=VALUE` pairs to semicolons. Using this approach I wrote rather
good-looking and good-working code to show information on threads in
Emacs.
That was a bit of a misplaced status report from me :) so I'll proceed to
some thoughts I had from my experience with GDB.
There is a dark corner in GDB/MI Output Syntax (section 26.2.2 of the
GDB manual) which doesn't fit to simple object model (for example, the
one JSON presents). This is the following case:
`LIST ==>'
` "[" RESULT ( "," RESULT )* "]" '
It looks badly wicked and all broken to me to have things like this in
MI output (this is from `break-info`):
body=[bkpt={number="1", â },bkpt={number="2", â}]
I feel that this should produce the following output instead:
body=[{number="1", â },{number="2", â}]
`-stack-list-frames` is another command which uses this evil notation.
It is evil because it disallows thinking of tuples as objects and of
lists as, well, plain lists. This abuses the notion of a list! Moreover,
this makes TUPLEs *redundant* parts of GDB/MI, as they turn out to be a
subset of LISTs with curly braces instead of square brackets.
I wonder why was GDB/MI syntax designed this way. I believe it ought to
be changed (that would be backwards-incompatible, though, and a lot of
front-ends would get broken).
The other question is, why not use JSON in GDB/MI at all? Look like
there are no such cases where GDB/MI information cannot be successfully
expressed with JSON. Utilizing that would lower costs of production for
various GDB front-ends because there would be no need to maintain extra
parser for MI instead of using JSON parser which can also be used in a
number of other applications.
Comments from MI developers are welcome!
--
Happy Hacking.
http://sphinx.net.ru
ã