Re: MI async status output

[Bob Rossi <bob@brasko.net>]

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