Re: GDB/MI Output Syntax

[Bob Rossi <bob@brasko.net>]

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