From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18878 invoked by alias); 7 Jan 2005 01:12:22 -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 18658 invoked from network); 7 Jan 2005 01:12:12 -0000 Received: from unknown (HELO lakermmtao06.cox.net) (68.230.240.33) by sourceware.org with SMTP; 7 Jan 2005 01:12:12 -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 <20050107011210.EHOG7687.lakermmtao06.cox.net@white>; Thu, 6 Jan 2005 20:12:10 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Cmifj-0007hD-00; Thu, 06 Jan 2005 20:12:11 -0500 Date: Fri, 07 Jan 2005 01:12:00 -0000 From: Bob Rossi To: Jim Ingham Cc: Eli Zaretskii , mec.gnu@mindspring.com, gdb@sources.redhat.com Subject: Re: GDB/MI Output Syntax Message-ID: <20050107011211.GB29435@white> Mail-Followup-To: Jim Ingham , Eli Zaretskii , mec.gnu@mindspring.com, gdb@sources.redhat.com References: <1093622671.2836.ezmlm@sources.redhat.com> <76E69B58-F852-11D8-8E70-000A958F4C44@apple.com> <412F87A4.nail3LU117EOV@mindspring.com> <20050105232657.GB27494@white> <01c4f3aa$Blat.v2.2.2$b4217d20@zahav.net.il> <20050106233136.GA29435@white> <4CE93165-C27F-4CF6-90B8-7632A7BD2672@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CE93165-C27F-4CF6-90B8-7632A7BD2672@apple.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-01/txt/msg00055.txt.bz2 On Thu, Jan 06, 2005 at 04:36:13PM -0800, Jim Ingham wrote: > Sorry for not responding, we're really busy here right now. > > I don't think there is any way to use your parser that won't involve > changing the testsuite files. After all, they are just passing regular > expressions, and unless you are ALSO willing to write a parser that > turns the mi testsuite regular expressions into some sensible form (not > something I would suggest) you are going to have to rewrite these > tests. OK, so rewriting the tests is fine. They are not very complicated. > I was more thinking of this as a project that you would use to write > new tests, and then any time a change in the mi output broke a test > case, you could rewrite it using the new form - since you are going to > have to rewrite it anyway... That's sounds OK. However, I would like to rewrite a few of them now, so that I can test that the parser is working. > The way that I was thinking to use the parser, is to write a command > like: "gdb_mi_parse_output" that would take the mi output, run your > parser on it, and turn the result into some Tcl data structure. This > would be a C based command, so we would have to build a little Tcl > extension to do this, and include it with gdb when we ran the test > suite. Here's the deal, I already have the C function that takes an MI output command, parses it, and returns a tree that represents the command. int gdbmi_parser_parse_string ( gdbmi_parser_ptr parser, /* a gdbmi parser context */ const char *mi_command, /* command the parser should parse */ gdbmi_output_ptr *pt ); /* The parse tree */ If Tcl is like C (struct, enum's, union's) I could easily put the parse tree declaration in some common file and generate both the C and the Tcl data structures. This part could be done in just a few days if I could get some guidance on how Tcl works. > The mi output is all basically just nested lists, so you could probably > express it as a nested list pretty easily. I'd have to think a bit > about how to design this well. Anyway, then you could rewrite the test > suite cases to just pull fields out of the Tcl data structure, and see > if the values were what was expected. This part I could do also. In fact, I need to do essentially this to make my front end work. It's all the same code. I think taking this step would do a lot in the sense of standardizing the output of GDB/MI. > Unfortunately, I am definitely not going to have any time to work on > this in the next little while, however. If you could help me with some technical details, I'd be happy to do the rest of the work. Is this possible or are you just to maxed out? Thanks, Bob Rossi