This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]