From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15481 invoked by alias); 30 May 2009 16:44:33 -0000 Received: (qmail 15466 invoked by uid 22791); 30 May 2009 16:44:32 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 May 2009 16:44:24 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MARfQ-0007hB-T0 for gdb@sources.redhat.com; Sat, 30 May 2009 16:44:20 +0000 Received: from 95-24-111-85.broadband.corbina.ru ([95.24.111.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 May 2009 16:44:20 +0000 Received: from dima by 95-24-111-85.broadband.corbina.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 May 2009 16:44:20 +0000 To: gdb@sources.redhat.com From: Dmitry Dzhus Subject: Re: GDB frontends, MI-speak and object notation Date: Sat, 30 May 2009 16:44:00 -0000 Message-ID: <87r5y6y22h.fsf@sphinx.net.ru> References: <87d49tv3z2.fsf@sphinx.net.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00193.txt.bz2 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 む