Re: GDB/MI Output Syntax

[Bob Rossi <bob@brasko.net>]

On Wed, Jan 05, 2005 at 07:27:48PM -0500, Paul Schlie wrote:
> > Bob Rossi wrote:
> >> Michael Chastain wrote:
> >> ...
> >> It would be much better to use TCL data structures to parse MI rather
> >> than regular expressions.  I had a great experience getting away from
> >> regular expressions with cp_test_ptype_class.
> >> 
> >> It's still a dozen host arches (actually, a dozen build arches,
> >> TCL runs on build machine).  But we're not debugging a target program
> >> with shared libraries, we're just using one as a host.
> >> ...
> >
> > Hey, has anything ever evolved out of this?
> > 
> > Here is my road map for developing an MI parser for CGDB.
> >   
> >   1. Create a grammar that is easily translated into LR(1)
> >   2. Generate the parser with flex and bison
> >   3. Have the parser test the output of the GDB MI testsuite
> >      (Don't know how to do this)
> >   4. Have the parser verify the semantics of GDB's output.
> > ...
> 
> Or how about a basic scheme (<keyword> <expression> ...) syntax, can't get
> much simpler or more flexible than that, not to mention it's fairly straight
> forward easy to read/parse/extend and may realativly easily accomplished by
> imbedding an open-source basic scheme interpreter, vs re-inventing the
> wheel; nearly eliminating the necessity for steps 1, 2; and longer term
> could easily eliminate gdb's present less than flexible command interpreter,
> as there's truly no good reason for the two to be distinct. (Not a new
> notion; but possibly timely and arguably far more productive than developing
> yet another yet another syntax/language/intepreter/etc.)

I understand your point here. Here's the state of affair's as far as I
see it

I want to write a curses based front end to GDB. I looked at the
alternatives for communicating with GDB and found that MI was the
documented way to do this. So, with that in mind I started to look for a
parser and grammar and none were found. This frustrated me cause i
didn't want to write one, so I suggested GDB output XML. Everyone
hated this idea. So, I decided to write the parser that everyone else
could use from here on out, so no one would have to reinvent the wheel.

I've already put some effort into the MI and this is the point that I'm
currently at. The goal I'm shooting for is to use this parser to really
validate the output of the MI. Better than is being done know. Make sure
the syntax and the semantics are perfect.

Basically, I'm not looking into writing a whole new frame work for
communicating with GDB, I just want to improve what's already there.

Thanks,
Bob Rossi