From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8872 invoked by alias); 13 Jan 2005 02:23:10 -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 8798 invoked from network); 13 Jan 2005 02:22:59 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 13 Jan 2005 02:22:59 -0000 Received: from white ([68.9.64.121]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050113022253.FIYB1713.lakermmtao09.cox.net@white>; Wed, 12 Jan 2005 21:22:53 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CoudS-00025w-00; Wed, 12 Jan 2005 21:22:54 -0500 Date: Thu, 13 Jan 2005 02:23:00 -0000 From: Bob Rossi To: Russell Shaw , gdb@sources.redhat.com Subject: Re: GDB/MI Output Syntax Message-ID: <20050113022254.GA8043@white> Mail-Followup-To: Russell Shaw , 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> <20050107011211.GB29435@white> <41DDFF0D.5040205@netspace.net.au> <20050111193526.GA5699@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050111193526.GA5699@white> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-01/txt/msg00065.txt.bz2 Hi, Any feedback? Either everyone's really busy, no one cares, or everyone love's this approach. At least we're all agreeing. :) Since I haven't received any feedback, I'm going to write it this way. I should have something workable within a week. Although, I don't know how to load this into expect yet. I'm assuming I'll have to recompile expect and link in tcl as a shared library, along with my extension. Thanks, Bob Rossi On Tue, Jan 11, 2005 at 02:35:26PM -0500, Bob Rossi wrote: > On Fri, Jan 07, 2005 at 02:16:29PM +1100, Russell Shaw wrote: > > Bob Rossi wrote: > > ... > > >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. > > > > A very comprehensive book: Pactical Programming in Tcl and Tk. > > Another book that explains TCL and also Expect (probably of more > > immediate use): Exploring Expect. Expect also has a large man page. > > > > C and TCL is like comparing chalk and cheese. TCL is interpreted too. > > Thanks for the info, I looked at "Practical Programming" and it helped me > out a lot! > > So, here is my initial design, can I get any feedback? > > Basically, I have a parser that I generated using flex/bison. That > parser is capable of parsing an MI output command and putting it into a > syntax tree. This is all done in C. > > To get the data into Tcl for the testsuite I had to write a Tcl > extension. The design I chose from the Tcl side is something like this. > > Here is part of the parse tree on the C side, > /** > * This is the root of a parsed GDB/MI Output command. > */ > struct gdbmi_output { > /** > * Every output command has a list of optional oob_record's. > * This will be the head of the list, otherwise NULL. > */ > gdbmi_oob_record_ptr oob_record; > > /** > * Every output command has an optional result_record. > * list, otherwise NULL. > */ > gdbmi_result_record_ptr result_record; > > /** A pointer to the next output */ > gdbmi_output_ptr next; > }; > > This is the Tcl side which understands how to access this data. > > # ------------ 'struct gdbmi_output' documentation > > # This function will parse an MI output command and return a > # reference to the syntax tree created. > # > # Arguments: > # mi_output_command is the string representing the MI output > # command that should be parsed and returned. > # > # Results: > # The string representing the gdbmi_output record. This in itself > # is not very useful, but can be operated on by the gdbmi_* commands. > # > proc gdbmi_parse_output_record {mi_output_command} > > # This function takes in a parse tree and get's the gdbmi_oob_record > # from the parse tree context. > # > # Arguments: > # gdbmi_output is the gdbmi_output command that came from > # gdbmi_parse_output_record > # > # Results: > # A string representing an gdbmi_oob_record record > # > proc gdbmi_get_oob_record {gdbmi_output} > > # This function takes in a parse tree and get's the gdbmi_result_record > # from the parse tree context. > # > # Arguments: > # gdbmi_output is the gdbmi_output command that came from > # gdbmi_parse_output_record > # > # Results: > # A string representing a gdbmi_result_record record > # > proc gdbmi_get_result_record {gdbmi_output} > > > >From this, I think it would be possible to query the syntax tree in the > Tcl. This would allow the testsuite to verify the syntax and possible the > semantics of the gdb/mi output commands. > > This is the approach I'm working towards. Any comments or suggestions? > > In the end, it would also be possible to have the parser parse the > output command and then write another tcl command that fills in a data > structure for the specific command under test. This way the scripts do > not have to deal with the syntax tree directly, but an in memory > representation of the MI output command. That would look something like > this, > set mi_output_command [gdbmi_parse $mi_output_command] > set mi_break_output [gdbmi_get_breakoutput $mi_output_command] > > The downside to this approach is creating in memory representations of > the specific MI commands, the upside to this is not making the > testcase's deal with the syntax tree directly. Also, front ends' could > link to the C parser and get the in memory representation. > > Thanks, > Bob Rossi