From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20451 invoked by alias); 11 Jan 2005 19:35:57 -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 20215 invoked from network); 11 Jan 2005 19:35:27 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 11 Jan 2005 19:35:27 -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 <20050111193524.JLQF1713.lakermmtao09.cox.net@white>; Tue, 11 Jan 2005 14:35:24 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CoRna-0001VP-00; Tue, 11 Jan 2005 14:35:26 -0500 Date: Tue, 11 Jan 2005 19:35:00 -0000 From: Bob Rossi To: Russell Shaw Cc: gdb@sources.redhat.com Subject: Re: GDB/MI Output Syntax Message-ID: <20050111193526.GA5699@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DDFF0D.5040205@netspace.net.au> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-01/txt/msg00063.txt.bz2 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