This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB/MI Output Syntax
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