Re: MI async status output

[Bob Rossi <bob@brasko.net>]

On Fri, Apr 18, 2014 at 05:11:12PM +0400, Vladimir Prus wrote:
> On 18.04.2014 14:46, Bob Rossi wrote:
> 
> >>whereas MI has grammar, the fact that actual output does not always match the
> >>grammar is well known. This specific problem was not known to me.
> >>
> >>It is obviously possible to fix in a parser. It's also possible to fix in GDB,
> >>but as usual the question of what existing frontends might depend on this behaviour.
> >
> >Thanks for the response. I'm writing a new grammar that will be open
> >source that handles as many possible outputs that GDB outputs, for as
> >many possible GDB versions. I'm writing unit and system tests to
> >validate this effort.
> 
> Is this a part of some larger effort?

I'm interested in porting CGDB from annotations to MI.

I actually started this project 10 years ago, boy time flies,
  https://www.sourceware.org/ml/gdb/2004-08/msg00373.html
This time I plan on finishing the project.

See below for more thoughts on larger effort.

> >I'm taking notes every time i have to modify the parser to detail the
> >reasons why.
> >
> >When I'm done, perhaps we can update GDB's manual with the new grammar
> >that I constuct, considering the one in the manual is just plain wrong.
> 
> That would be helpful; ideally we'd clearly mark, in the grammar, the
> cases where actual GDB behaviour differs from desirable behaviour, so
> that these can be eliminated if anybody starts MI3.

Great, I'm working on the project here if anyone wants to pay attention,
  https://github.com/brasko/gdbwire
At first, the goal of the project will be to provide a light weight
GDB/MI parser written in C. I'm currently unit testing the grammar.

After that, I'm going to look into making an API to GDB. See below.

> Though quite possibly, MI3 should just accept and produce JSON.

I think it would be good to have an honest discussion on this topic.

It was really easy to write CGDB based on GDB annotations. The obvious
problem was that the annotations interface provides very little
information. So CGDB is very limited.

In steps GDB/MI. 
  - The GDB/MI grammar is wrong (fix it and you hit the semantic issues)
  - When GDB changes, how do the front ends handle the before and after?
    Problem: A 1 (GDB) to many (front end) relationship exists making it
    difficult to change or improve GDB.
  - How do front ends work with different versions of GDB?
    Problem: A 1 (front end) to many (GDB versions) relationship exists
    making it difficult for a front end to work well with any version of
    GDB. Front ends naturally suffer from a least common demoninator
    feature set. That is, only use the features available in most
    versions of GDB.

The solution to these problems is pretty clear, lets give developers an API.

Now front ends share the benefits of a common api, rather than every
front end dealing uniquely with all these issues, which is unrealistic.

Now GDB can change independent of the protocol. GDB can look at what
features it is affecting in the API while developing it's internal features.
It's a win win situation.

The API doesn't have to be internal to GDB. It could be gdbwire, a layer
that sits on top of GDB. That's the goal I'm pursuing in my spare time
for CGDB.

However, based on your comments about JSON, and the fact that the python
api is the latest development in automating GDB, I'm not even sure how
appropriate it is to write a front end on GDB using MI. Can anyone speak
to the long term viability of this protocol? I'd hate to port CGDB to
GDB/MI only to be told that it's been superseded by a new protocol.
    http://www.cygwin.com/ml/gdb/2003-02/msg00070.html

Thanks,
Bob Rossi