From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10856 invoked by alias); 5 Jan 2005 23:27:12 -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 10673 invoked from network); 5 Jan 2005 23:26:58 -0000 Received: from unknown (HELO lakermmtao11.cox.net) (68.230.240.28) by sourceware.org with SMTP; 5 Jan 2005 23:26:58 -0000 Received: from white ([68.9.64.121]) by lakermmtao11.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050105232657.DKLA1657.lakermmtao11.cox.net@white>; Wed, 5 Jan 2005 18:26:57 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CmKYL-0007A1-00; Wed, 05 Jan 2005 18:26:57 -0500 Date: Wed, 05 Jan 2005 23:27:00 -0000 From: Bob Rossi To: Michael Chastain Cc: jingham@apple.com, gdb@sources.redhat.com Subject: Re: GDB/MI Output Syntax Message-ID: <20050105232657.GB27494@white> Mail-Followup-To: Michael Chastain , jingham@apple.com, gdb@sources.redhat.com References: <1093622671.2836.ezmlm@sources.redhat.com> <76E69B58-F852-11D8-8E70-000A958F4C44@apple.com> <412F87A4.nail3LU117EOV@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412F87A4.nail3LU117EOV@mindspring.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-01/txt/msg00043.txt.bz2 On Fri, Aug 27, 2004 at 03:12:36PM -0400, Michael Chastain wrote: > Jim Ingham wrote: > > The problem is that the sample extension actually adds a command called > > "sha1". In interactive mode, tcl resolves shortened commands to the > > full name if the resolution is unique. > > *bonk* *bonk* *bonk* > > That's the sound of me banging my head against the wall. Stupid me! > > > I actually think that building Bob's parser into a Tcl C extension & > > using that with the DejaGnu testsuite would be brilliant. > > New vistas are opening up to me! > > 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. I basically believe I'm done with step 1 and 2, besides bugs and other stuff. After I'm done with step 3, I plan on adding the parser into CGDB. I may even wait until after step 4. My questions are, 1. will the grammar and bison syntax be good to document so that others can see it? 2. Can anyone help me put the parser into the testsuite ( It could take me forever since I know nothing about TCL, Excpect, ... ) 3. Would a patch like this be acceptable even if it was accomplished? Thanks, Bob Rossi