From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19612 invoked by alias); 6 Jan 2005 00:28:00 -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 19553 invoked from network); 6 Jan 2005 00:27:53 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 6 Jan 2005 00:27:53 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc12) with SMTP id <2005010600275101400sataie>; Thu, 6 Jan 2005 00:27:52 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 06 Jan 2005 00:28:00 -0000 Subject: Re: GDB/MI Output Syntax From: Paul Schlie To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-01/txt/msg00044.txt.bz2 > 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.)