This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI rules
On Wed, Sep 22, 2004 at 10:58:34AM -0400, Alain Magloire wrote:
> >
> >
> > >I currently have a set of rules that parse an MI output command. This
> > >includes the flex file, the bison file and an extra source file that
> > >populates an in memory data structure representing the MI output
> > >command.
> > >
> > >The rules from the documentation had to change only slightly to conform
> > >to what GDB is actually outputting. The problem is, I haven't tested the
> > >parser extensively. The reason for this is because I am waiting to here
> > >from the GDB developers how to interpret the data semantically once it
> > >is acquired. I believe that every MI output command needs to have a
> > >header describing what type of MI output command is being transmitted.
> > >With this knowledge, the front end would understand exactly what
> > >information it needs to grab from the parse tree. Otherwise, the front
> > >end gets confusing at best.
> >
> > How are the existing frontends doing it then? Do they just wait after
> > a sent command until they receive a reply and take it as the one they're
> > looking for?
> >
> > >BTW, I took a look at the eclipse MI parser, from what I can tell, it
> > >uses a hybrid MI/CLI approach, and simply parses the MI command with
> > >string compares. As far as I can tell, this method will be very buggy
> > >and confusing in the long run.
> >
>
> 8-), a very severe criticism.
> It is a hand written decent parser. It was simple to write instead of
> using JavaCC(flex/bison). The problem is not the parser but
> the non conformity or rather the lack of feature of the MI Protocol implementation,
> but that said it should not be seen as a complaint to the GDB folks,
> MI was a great step in the right direction.
I wasn't being critical at all. Personally, I don't like the fact that
Eclipse use's a hybrid approach to getting data out of GDB. I have not
even started adding MI to CGDB because I've been working on GDB,
bringing it up to the standards I need to get CGDB fully usable by only
using MI. If others would follow this approach, I'm sure my life would
have been a lot easier, and CGDB would have been far more along.
> > >string compares. As far as I can tell, this method will be very buggy
> > >and confusing in the long run.
>
> I'm not sure on what you base such analysis ... but patches are always
> welcome, it is an open source project.
> And if you have a performing MI parser in Java, please send it to the Eclipse/CDT
> folks, we will be ecstatic.
This isn't outlandish. You could easily convert the MI parse tree I've
created into XML, and do what you like with it on the Java side.
> > That's why I asked. There are Eclipse, KDevelop and I don't know how
> > many other frontends it's hard to believe they always wrote a new parser.
> > And even if they did was it handwritten or generated... I guess then I'm
> > looking forward to your results :)
> >
>
> Eclispe uses the Java language, I suppose KDevelop C++, or other languages.
> Writing a parser, is not the problem, or IMHO is not the problem
> that GDB was trying to solve(You can write a parser for MI within a day).
> Read the followup/feedback posts on the XMI proposals thread.
Anyways, hope I didn't insult you or the eclipse project, we are all working
on the same side here.
Bobby