Re: GDB frontends, MI-speak and object notation

[Vladimir Prus <vladimir at codesourcery dot com>]

Dmitry Dzhus wrote:

> 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. 

What makes you think it was designed? GDB/MI is not result of a design
session, but of somewhat long evolution, so some early decisions are
prominent.

> I believe it ought to 
> be changed (that would be backwards-incompatible, though, and a lot of
> front-ends would get broken).

So, that's only MI 3.0, in as yet unscheduled future.

> 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.

I am unsure about this point. GDB/MI parsers to exist and can be reused
by interested parties easily. Changing format to accommodate new frontend
at expense of existing frontends does not seem good idea.

- Volodya