From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2564 invoked by alias); 6 Jan 2005 01:10:55 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2516 invoked from network); 6 Jan 2005 01:10:37 -0000 Received: from unknown (HELO lakermmtao06.cox.net) (68.230.240.33) by sourceware.org with SMTP; 6 Jan 2005 01:10:37 -0000 Received: from white ([68.9.64.121]) by lakermmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050106011035.XZWX7687.lakermmtao06.cox.net@white>; Wed, 5 Jan 2005 20:10:35 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CmMAf-0007Ca-00; Wed, 05 Jan 2005 20:10:37 -0500 Date: Thu, 06 Jan 2005 01:10:00 -0000 From: Bob Rossi To: Paul Schlie Cc: gdb@sources.redhat.com Subject: Re: GDB/MI Output Syntax Message-ID: <20050106011036.GA27670@white> Mail-Followup-To: Paul Schlie , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2005-01/txt/msg00047.txt.bz2 On Wed, Jan 05, 2005 at 07:27:48PM -0500, Paul Schlie wrote: > > Bob Rossi wrote: > >> Michael Chastain wrote: > >> ... > >> It would be much better to use TCL data structures to parse MI rather > >> than regular expressions. I had a great experience getting away from > >> regular expressions with cp_test_ptype_class. > >> > >> It's still a dozen host arches (actually, a dozen build arches, > >> TCL runs on build machine). But we're not debugging a target program > >> with shared libraries, we're just using one as a host. > >> ... > > > > Hey, has anything ever evolved out of this? > > > > Here is my road map for developing an MI parser for CGDB. > > > > 1. Create a grammar that is easily translated into LR(1) > > 2. Generate the parser with flex and bison > > 3. Have the parser test the output of the GDB MI testsuite > > (Don't know how to do this) > > 4. Have the parser verify the semantics of GDB's output. > > ... > > Or how about a basic scheme ( ...) syntax, can't get > much simpler or more flexible than that, not to mention it's fairly straight > forward easy to read/parse/extend and may realativly easily accomplished by > imbedding an open-source basic scheme interpreter, vs re-inventing the > wheel; nearly eliminating the necessity for steps 1, 2; and longer term > could easily eliminate gdb's present less than flexible command interpreter, > as there's truly no good reason for the two to be distinct. (Not a new > notion; but possibly timely and arguably far more productive than developing > yet another yet another syntax/language/intepreter/etc.) I understand your point here. Here's the state of affair's as far as I see it I want to write a curses based front end to GDB. I looked at the alternatives for communicating with GDB and found that MI was the documented way to do this. So, with that in mind I started to look for a parser and grammar and none were found. This frustrated me cause i didn't want to write one, so I suggested GDB output XML. Everyone hated this idea. So, I decided to write the parser that everyone else could use from here on out, so no one would have to reinvent the wheel. I've already put some effort into the MI and this is the point that I'm currently at. The goal I'm shooting for is to use this parser to really validate the output of the MI. Better than is being done know. Make sure the syntax and the semantics are perfect. Basically, I'm not looking into writing a whole new frame work for communicating with GDB, I just want to improve what's already there. Thanks, Bob Rossi