MI async status output

MI async status output

[Bob Rossi]

Hi,

I'm writing unit tests for my MI parser and was trying to get
GDB to output some out of band, async records of type:
status-async-output.

This type of output normally starts with a + according to the manual.

The manual has a special note that says:
status-async-output contains on-going status information about the
progress of a slow operation. It can be discarded. All status output is
prefixed by ‘+’. 

I built gdb from git/master and ran the mi test suite and looked
at the gdb.log file that was created. Unless I'm missing it, I don't see
this type of output anywhere.

Does this mean that GDB doesn't test this functionality?
Does anyone have a simple recipe for getting GDB to output some
async status output?

Thanks,
Bob Rossi

Re: MI async status output

[Vladimir Prus]

On 10.04.2014 01:08, Bob Rossi wrote:
> Hi,
>
> I'm writing unit tests for my MI parser and was trying to get
> GDB to output some out of band, async records of type:
> status-async-output.
>
> This type of output normally starts with a + according to the manual.
>
> The manual has a special note that says:
> status-async-output contains on-going status information about the
> progress of a slow operation. It can be discarded. All status output is
> prefixed by ‘+’.
>
> I built gdb from git/master and ran the mi test suite and looked
> at the gdb.log file that was created. Unless I'm missing it, I don't see
> this type of output anywhere.
>
> Does this mean that GDB doesn't test this functionality?
> Does anyone have a simple recipe for getting GDB to output some
> async status output?

Bob,

I think the only case where "+" notification is used is load command with sufficiently
big binary. See mi-main.c:mi_load_progress. I don't know whether it can be triggered
without bare-metal target.

- Volodya

Re: MI async status output

[Vladimir Prus]

On 10.04.2014 01:08, Bob Rossi wrote:
> Hi,
>
> I'm writing unit tests for my MI parser and was trying to get
> GDB to output some out of band, async records of type:
> status-async-output.
>
> This type of output normally starts with a + according to the manual.
>
> The manual has a special note that says:
> status-async-output contains on-going status information about the
> progress of a slow operation. It can be discarded. All status output is
> prefixed by ‘+’.
>
> I built gdb from git/master and ran the mi test suite and looked
> at the gdb.log file that was created. Unless I'm missing it, I don't see
> this type of output anywhere.
>
> Does this mean that GDB doesn't test this functionality?
> Does anyone have a simple recipe for getting GDB to output some
> async status output?

Bob,

I think the only case where "+" notification is used is load command with sufficiently
big binary. See mi-main.c:mi_load_progress. I don't know whether it can be triggered
without bare-metal target.

- Volodya

Re: MI async status output

[Bob Rossi]

On Thu, Apr 10, 2014 at 07:00:54PM +0400, Vladimir Prus wrote:
> On 10.04.2014 01:08, Bob Rossi wrote:
> >I'm writing unit tests for my MI parser and was trying to get
> >GDB to output some out of band, async records of type:
> >status-async-output.
...
> >Does anyone have a simple recipe for getting GDB to output some
> >async status output?
> 
> I think the only case where "+" notification is used is load command
> with sufficiently big binary. See mi-main.c:mi_load_progress. I don't
> know whether it can be triggered without bare-metal target.

It's unobvious to me how to get GDB to trigger this functionality.

I'd be greatful if anyone could show a quick example getting code
coverage on GDB where the mi-main.c:mi_load_progress code is hit
which outputs the 
      fputs_unfiltered ("+download", raw_stdout);
lines (or similiar async status output in GDB).

Any takers?

Thanks,
Bob Rossi

Re: MI async status output

[Andrew Burgess]

On 10/04/2014 9:12 PM, Bob Rossi wrote:
> On Thu, Apr 10, 2014 at 07:00:54PM +0400, Vladimir Prus wrote:
>> On 10.04.2014 01:08, Bob Rossi wrote:
>>> I'm writing unit tests for my MI parser and was trying to get
>>> GDB to output some out of band, async records of type:
>>> status-async-output.
> ...
>>> Does anyone have a simple recipe for getting GDB to output some
>>> async status output?
>>
>> I think the only case where "+" notification is used is load command
>> with sufficiently big binary. See mi-main.c:mi_load_progress. I don't
>> know whether it can be triggered without bare-metal target.
> 
> It's unobvious to me how to get GDB to trigger this functionality.
> 
> I'd be greatful if anyone could show a quick example getting code
> coverage on GDB where the mi-main.c:mi_load_progress code is hit
> which outputs the 
>       fputs_unfiltered ("+download", raw_stdout);
> lines (or similiar async status output in GDB).

It's triggered as part of the progress update for MI loads.  The
progress callback is called at least, for each section that is
loaded.

I did the this:

1. Build hello-world test program, which contained at least a .text and
.data section.
2. Start gdbserver as: gdbserver :1234 helloworld.exe
3. Start gdb as: gdb -i mi helloworld.exe
4. Within gdb:
   (gdb) -target-select remote :1234
   (gdb) -target-download
   # Bunch of +download lines
   # Single ^done line.

Hope that helps,
Andrew

Re: MI async status output

[Bob Rossi]

On Fri, Apr 11, 2014 at 11:01:40AM +0100, Andrew Burgess wrote:
> On 10/04/2014 9:12 PM, Bob Rossi wrote:
> > On Thu, Apr 10, 2014 at 07:00:54PM +0400, Vladimir Prus wrote:
> >> On 10.04.2014 01:08, Bob Rossi wrote:
> >>> I'm writing unit tests for my MI parser and was trying to get
> >>> GDB to output some out of band, async records of type:
> >>> status-async-output.
> > ...
> >>> Does anyone have a simple recipe for getting GDB to output some
> >>> async status output?
> >>
> >> I think the only case where "+" notification is used is load command
> >> with sufficiently big binary. See mi-main.c:mi_load_progress. I don't
> >> know whether it can be triggered without bare-metal target.
> > 
> > It's unobvious to me how to get GDB to trigger this functionality.
> > 
> > I'd be greatful if anyone could show a quick example getting code
> > coverage on GDB where the mi-main.c:mi_load_progress code is hit
> > which outputs the 
> >       fputs_unfiltered ("+download", raw_stdout);
> > lines (or similiar async status output in GDB).
> 
> It's triggered as part of the progress update for MI loads.  The
> progress callback is called at least, for each section that is
> loaded.
> 
> I did the this:
> 
> 1. Build hello-world test program, which contained at least a .text and
> .data section.
> 2. Start gdbserver as: gdbserver :1234 helloworld.exe
> 3. Start gdb as: gdb -i mi helloworld.exe
> 4. Within gdb:
>    (gdb) -target-select remote :1234
>    (gdb) -target-download
>    # Bunch of +download lines
>    # Single ^done line.

Thanks! That worked great!

I wouldn't have thought of using gdbserver.

Thanks again,
Bob Rossi

Re: MI async status output

[Bob Rossi]

On Fri, Apr 11, 2014 at 11:01:40AM +0100, Andrew Burgess wrote:
> On 10/04/2014 9:12 PM, Bob Rossi wrote:
> > On Thu, Apr 10, 2014 at 07:00:54PM +0400, Vladimir Prus wrote:
> >> On 10.04.2014 01:08, Bob Rossi wrote:
> >>> I'm writing unit tests for my MI parser and was trying to get
> >>> GDB to output some out of band, async records of type:
> >>> status-async-output.
> > ...
> >>> Does anyone have a simple recipe for getting GDB to output some
> >>> async status output?
> >>
> >> I think the only case where "+" notification is used is load command
> >> with sufficiently big binary. See mi-main.c:mi_load_progress. I don't
> >> know whether it can be triggered without bare-metal target.
> > 
> > It's unobvious to me how to get GDB to trigger this functionality.
> > 
> > I'd be greatful if anyone could show a quick example getting code
> > coverage on GDB where the mi-main.c:mi_load_progress code is hit
> > which outputs the 
> >       fputs_unfiltered ("+download", raw_stdout);
> > lines (or similiar async status output in GDB).
> 
> It's triggered as part of the progress update for MI loads.  The
> progress callback is called at least, for each section that is
> loaded.
> 
> I did the this:
> 
> 1. Build hello-world test program, which contained at least a .text and
> .data section.
> 2. Start gdbserver as: gdbserver :1234 helloworld.exe
> 3. Start gdb as: gdb -i mi helloworld.exe
> 4. Within gdb:
>    (gdb) -target-select remote :1234
>    (gdb) -target-download
>    # Bunch of +download lines
>    # Single ^done line.

Thanks! Unfortunately, GDB is dumping invalid MI here.

When I run -target-download, I get this:
    ...
    +download,{section=".interp",section-size="28",total-size="2466"}
    ...
    ^done...
    (gdb) 

The MI rules are:
1)
    +download,{section=".interp",section-size="28",total-size="2466"}
    ^ (+ eaten here)
    status-async-output ==>
        [ token ] "+" async-output nl

2)
    +download,{section=".interp",section-size="28",total-size="2466"}
     ^ (download eaten by async-class)
    async-output ==>
        async-class ( "," result )* 
    async-class ==>
        "stopped" | others (where others includes download i guess)
    
3)
    +download,{section=".interp",section-size="28",total-size="2466"}
             ^ (, eaten here)
    async-output ==>
        async-class ( "," result )* 

4) Error here: result must start with a variable name.
    +download,{section=".interp",section-size="28",total-size="2466"}
              ^ (syntax error)
    result ==>
        variable "=" value
    variable ==>
        string 

Did I find a bug or is this well known behavior of GDB and MI?

If it's well known behavior, can anyone explain it? It's possible that
result could be just a 'value' instead of 'variable = value'. In this
case that would solve the problem perhaps.

Any advice would be appreciated.

Thanks,
Bob Rossi

Re: MI async status output

[Bob Rossi]

On Fri, Apr 11, 2014 at 08:25:38PM -0400, Bob Rossi wrote:
> On Fri, Apr 11, 2014 at 11:01:40AM +0100, Andrew Burgess wrote:
> > On 10/04/2014 9:12 PM, Bob Rossi wrote:
> > > On Thu, Apr 10, 2014 at 07:00:54PM +0400, Vladimir Prus wrote:
> > >> On 10.04.2014 01:08, Bob Rossi wrote:
> > >>> I'm writing unit tests for my MI parser and was trying to get
> > >>> GDB to output some out of band, async records of type:
> > >>> status-async-output.
> > > ...
> > >>> Does anyone have a simple recipe for getting GDB to output some
> > >>> async status output?
...
> > I did the this:
> > 1. Build hello-world test program
> > 2. Start gdbserver as: gdbserver :1234 helloworld.exe
> > 3. Start gdb as: gdb -i mi helloworld.exe
> > 4. Within gdb:
> >    (gdb) -target-select remote :1234
> >    (gdb) -target-download
> >    # Bunch of +download lines
...
> Thanks! Unfortunately, GDB is dumping invalid MI here.
>     ...
>     +download,{section=".interp",section-size="28",total-size="2466"}
>     ...
>     ^done...
>     (gdb) 
> 
> The MI rules are:
> 1)
>     +download,{section=".interp",section-size="28",total-size="2466"}
>     ^ (+ eaten here)
>     status-async-output ==>
>         [ token ] "+" async-output nl
> 
> 2)
>     +download,{section=".interp",section-size="28",total-size="2466"}
>      ^ (download eaten by async-class)
>     async-output ==>
>         async-class ( "," result )* 
>     async-class ==>
>         "stopped" | others (where others includes download i guess)
>     
> 3)
>     +download,{section=".interp",section-size="28",total-size="2466"}
>              ^ (, eaten here)
>     async-output ==>
>         async-class ( "," result )* 
> 
> 4) Error here: result must start with a variable name.
>     +download,{section=".interp",section-size="28",total-size="2466"}
>               ^ (syntax error)
>     result ==>
>         variable "=" value
>     variable ==>
>         string 
> 
> Did I find a bug or is this well known behavior of GDB and MI?
> 
> If it's well known behavior, can anyone explain it? It's possible that
> result could be just a 'value' instead of 'variable = value'. In this
> case that would solve the problem perhaps.
> 
> Any advice would be appreciated.

Ping.

Bob Rossi

Re: MI async status output

[Vladimir Prus]

On 12.04.2014 04:25, Bob Rossi wrote:

> 3)
>      +download,{section=".interp",section-size="28",total-size="2466"}
>               ^ (, eaten here)
>      async-output ==>
>          async-class ( "," result )*
>
> 4) Error here: result must start with a variable name.
>      +download,{section=".interp",section-size="28",total-size="2466"}
>                ^ (syntax error)
>      result ==>
>          variable "=" value
>      variable ==>
>          string
>
> Did I find a bug or is this well known behavior of GDB and MI?
>
> If it's well known behavior, can anyone explain it? It's possible that
> result could be just a 'value' instead of 'variable = value'. In this
> case that would solve the problem perhaps.

Bob,

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.

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Re: MI async status output

[Bob Rossi]

On Fri, Apr 18, 2014 at 12:20:25PM +0400, Vladimir Prus wrote:
> On 12.04.2014 04:25, Bob Rossi wrote:
> 
> >3)
> >     +download,{section=".interp",section-size="28",total-size="2466"}
> >              ^ (, eaten here)
> >     async-output ==>
> >         async-class ( "," result )*
> >
> >4) Error here: result must start with a variable name.
> >     +download,{section=".interp",section-size="28",total-size="2466"}
> >               ^ (syntax error)
> >     result ==>
> >         variable "=" value
> >     variable ==>
> >         string
> >
> >Did I find a bug or is this well known behavior of GDB and MI?
> >
> >If it's well known behavior, can anyone explain it? It's possible that
> >result could be just a 'value' instead of 'variable = value'. In this
> >case that would solve the problem perhaps.
> 
> 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.

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.

Thanks,
Bob Rossi

Re: MI async status output

[Vladimir Prus]

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 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.

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

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Re: MI async status output

[Bob Rossi]

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

Re: MI async status output

[Vladimir Prus]

On 18.04.2014 20:30, Bob Rossi wrote:
>> 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.

I am not sure what's different between "API" and GDB/MI, which is also an API
or some sort. No matter what a new API might be, the problems of GDB changes
and supporting multiple versions of GDB will be the same, except for wrong
grammar. Web developers have the same problems with API changes, for all I know.

> 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

I mention JSON in part because GDB/MI grammar is rather similar to it
already. Saying "it's just JSON" would mean GDB folks don't have to deal
with insignificant syntax matters. Also, it would make it rather easy
to add a Python function callable by frontend that would output data
frontend can parse - using JSON support in Python is way easier than
Python binding for GDB ui_ machinery.

- Volodya

-- 
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Re: MI async status output

[Bob Rossi]

On Fri, Apr 18, 2014 at 08:42:33PM +0400, Vladimir Prus wrote:
> On 18.04.2014 20:30, Bob Rossi wrote:
> >>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.
> 
> I am not sure what's different between "API" and GDB/MI, which is also an API
> or some sort.

I think I spelled that out pretty clearly. The library providing the API
solves the problem, so that every implementation doesn't have to.

> >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
> 
> I mention JSON in part because GDB/MI grammar is rather similar to it
> already. Saying "it's just JSON" would mean GDB folks don't have to deal
> with insignificant syntax matters.

But now all N front ends need to be modified to handle mi1, mi2 or json.

> Also, it would make it rather easy
> to add a Python function callable by frontend that would output data
> frontend can parse - using JSON support in Python is way easier than
> Python binding for GDB ui_ machinery.

Agreed. I plan on wrapping gdbwire with swig to provide python api's.

In the short term, you might see some emails for me, asking about
specific oddities in the GDB/MI protocol. This will be an an effort to
provide a robust API. In the long term, we'll see how many edge case's
there really are and perhaps decide where to go from there.

Thanks!
Bob Rossi

RE: MI async status output

[Terekhov, Mikhail]

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Vladimir Prus
> Sent: Friday, April 18, 2014 12:43 PM
> To: Bob Rossi
> Cc: Andrew Burgess; gdb@sourceware.org
> Subject: Re: MI async status output
> 
> On 18.04.2014 20:30, Bob Rossi wrote:
> >
> > The solution to these problems is pretty clear, lets give developers an API.
> 
> I am not sure what's different between "API" and GDB/MI, which is also an
> API or some sort. No matter what a new API might be, the problems of GDB
> changes and supporting multiple versions of GDB will be the same, except for
> wrong grammar. Web developers have the same problems with API changes,
> for all I know.
> 

The difference is very important - in case of grammar the only way to verify that GDB
really follows it is to write and maintain complete set of test cases while in case of API
compiler will do it for you automatically. The situation with MI clearly shows that and
JSON will be no different in this regard. That doesn't mean that there is no need to
verify that this API works correctly of course :}

Regards,
Mikhail

Re: MI async status output

[Bob Rossi]

On Fri, Apr 18, 2014 at 03:27:03PM -0400, Terekhov, Mikhail wrote:
> > -----Original Message-----
> > From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> > Behalf Of Vladimir Prus
> > Sent: Friday, April 18, 2014 12:43 PM
> > To: Bob Rossi
> > Cc: Andrew Burgess; gdb@sourceware.org
> > Subject: Re: MI async status output
> > 
> > On 18.04.2014 20:30, Bob Rossi wrote:
> > >
> > > The solution to these problems is pretty clear, lets give developers an API.
> > 
> > I am not sure what's different between "API" and GDB/MI, which is also an
> > API or some sort. No matter what a new API might be, the problems of GDB
> > changes and supporting multiple versions of GDB will be the same, except for
> > wrong grammar. Web developers have the same problems with API changes,
> > for all I know.
> > 
> 
> The difference is very important - in case of grammar the only way to verify that GDB
> really follows it is to write and maintain complete set of test cases while in case of API
> compiler will do it for you automatically.

I can see that the acronym API is really an ambiguous term here.

The API i'm refering to is something like,
    void gdbwire_set_breakpoint(char *file, int line);
Asking GDB to set a breakpoint, interpreting the response.

It should also be possible to recieve events, like when the breakpoint
was hit. This opens the library up to dozens of possible combinations.
    - How does gdb respond to breakpoints for C or ada?
    - How does gdb respond to breakpoints in 2004 vs 2014
    - What version of MI is being used?

I'm being idealistic I know. When writing a front end, I really don't
want to deal with these details. The way GDB is designed now, it forces
me to. In fact, it forces everyone to. I'm trying to help mitigate that
problem. Lets see how it goes.

Bob Rossi