Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Dmitry Dzhus <dima@sphinx.net.ru>
To: gdb@sources.redhat.com
Subject: Re: GDB frontends, MI-speak and object notation
Date: Sat, 30 May 2009 16:44:00 -0000	[thread overview]
Message-ID: <87r5y6y22h.fsf@sphinx.net.ru> (raw)
In-Reply-To: <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
ã‚€


  parent reply	other threads:[~2009-05-30 16:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-28 12:00 Dmitry Dzhus
2009-05-28 13:32 ` Marc Khouzam
2009-05-28 13:57   ` André Pönitz
2009-05-29  9:25     ` Dmitry Dzhus
2009-05-29 15:30       ` Marc Khouzam
2009-05-30 16:44 ` Dmitry Dzhus [this message]
2009-05-30 19:24   ` Vladimir Prus
2009-05-30 21:27   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r5y6y22h.fsf@sphinx.net.ru \
    --to=dima@sphinx.net.ru \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox