Re: GDB/MI Output Syntax

[Bob Rossi <bob@brasko.net>]

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