This is the mail archive of the 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: How about remote MI?

>  > BTW, I am trying to make vim2gdb (An vim plug-in to make vim can debug
>  > code through GDB. It use GDBRUI in before.) support MI. But the MI
>  > output format is not very easy to parse. Could some people recommend a
>  > programe or example that parse the MI output for me? If not, I think I
>  > will use lex to parse it.
> I think the idea is that the front end parses it directly.  Generating an
> intermediate langusage just adds to the complexity.  If you think MI can
> be improved then please make suggestions.

This is simply not true. It is possible to write an MI parser that "works".
However, AFAIK, no one (besides maybe eclispse) has written a production 
quality MI parser that works under all cicumstances, is well tested, ...

Having everyone use there own parser is a lose-lose situation. It will
add to the MI maintaince burden with loads of questions per developer,
it will waste every projects time that wants a parser, and it will give
the community at large a bad sense of GDB front ends (which it already
has BTW) because each not fully tested MI parser will fail in slightly
different boundry cases.

I have started an effort here to provide an MI parser. It is far from
complete. It is not well tested. It does not have documentation.
However, it does syntacticaly parse the output of the test suite.

svn co

Sometime in the future I will get more time and will eventually get
this silly parser complete. At this point, you can use it to get an AST
of the MI, which is still very useful.

Bob Rossi

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