Re: GDB/MI snapshots between major release's

Re: GDB/MI snapshots between major release's

[Jason Molenda]

On Mon, Oct 04, 2004 at 11:12:01AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > With the information I have now, here is the problem. A snapshot of GDB
> > will say that it is at MI4, although, it is really at some
> > developmental version.
> 
> does that ever happen? if gdb says it supports MI4 but it
> doesn't really, then it's lying, and that's a bug. 

For what it's worth, Bob does have a point here.

When an incompatible change to MI is made, the version # is bumped.
From that point in time until the new MI version is "finalized",
it's usually a free-for-all to add whatever changes you want into
the new MI version.

I don't know if there's an official way of telling whether a
particular MI version has been finalized -- personally, I think of
the highest MI version as being the in-development one, which is
subject to change.

I don't really agree with the problem Bob is pointing out,
personally.  If I were writing a front end, I'd target the
highest stable version I can rely on (these days that would
be MI2), and use that.  Or if I didn't really need the changes
in MI2, I'd target MI1.

I do see some legitimate problems that Bob is raising.

 1. I don't know of an official way to tell if an MI command set
    has been finalized.  The policy I outlined above -- the highest
    # MI command set is in development, until the version # is bumped --
    is my own understanding, but it might be wrong.

 2. There isn't any way for a front end developer to tell exactly
    what the MI differences are without looking at the source.  I
    know old gdb releases' documentation should make this clear,
    but I'd be surprised if it's really clear enough to write an
    implementation from.

 3. Is there a guarantee that old MI interfaces will be supported?
    Or will we wake up to find gdb 6.3 has deprecated, e.g. MI1, and
    scheduled it for purging?

Realistically, the changes to MI are not dramatic; they're almost
always additions that can be ignored if the front end wasn't expecting
them -- that was the whole point of the MI output design.  The most
obvious break was mi0 vs mi1, but that was a long time ago.

On the other hand, the reason the MI interface has been so stable is
(IMHO) because there are so few shipping FEs that use it.  Apple has
one, and we've got quite a large number of changes in the MI.  I
understand Eclipse is now using it -- the resurgance of work on the
FSF gdb MI interface these past couple years is the evidence of that.
As more FEs start using MI, I expect there to be more changes, or
at least more requests for changes, to the protocol.  And so these
sorts of issues could legitimately be important to set down.

Jason

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 12:24:39PM -0700, Jason Molenda wrote:
> On Mon, Oct 04, 2004 at 11:12:01AM -0700, Felix Lee wrote:
> > Bob Rossi <bob@brasko.net>:
> > > With the information I have now, here is the problem. A snapshot of GDB
> > > will say that it is at MI4, although, it is really at some
> > > developmental version.
> > 
> > does that ever happen? if gdb says it supports MI4 but it
> > doesn't really, then it's lying, and that's a bug. 
> 
> For what it's worth, Bob does have a point here.
> 
> When an incompatible change to MI is made, the version # is bumped.
> >From that point in time until the new MI version is "finalized",
> it's usually a free-for-all to add whatever changes you want into
> the new MI version.
> 
> I don't know if there's an official way of telling whether a
> particular MI version has been finalized -- personally, I think of
> the highest MI version as being the in-development one, which is
> subject to change.
> 
> I don't really agree with the problem Bob is pointing out,
> personally.  If I were writing a front end, I'd target the
> highest stable version I can rely on (these days that would
> be MI2), and use that.  Or if I didn't really need the changes
> in MI2, I'd target MI1.

Yes yes, of course I am going to try to target the highest protocol that
the current GDB supports. The first implementation I write will be MI2.
The whole point of this thread is basically to figure out from GDB what
the highest stable protocol of MI that it supports is, and use it. I
want to be able to determine this even if GDB is not an official
release, but just a CVS snapshot.

> I do see some legitimate problems that Bob is raising.
> 
>  1. I don't know of an official way to tell if an MI command set
>     has been finalized.  The policy I outlined above -- the highest
>     # MI command set is in development, until the version # is bumped --
>     is my own understanding, but it might be wrong.

I basically need from GDB all of the MI versions that it supports. This
list should not include a development version of the MI protocol, that
is currently being worked on. If you have a CVS snapshot you currently
have no way of knowing that the highest MI protocol number is a
development version, and not an official release.

>  2. There isn't any way for a front end developer to tell exactly
>     what the MI differences are without looking at the source.  I
>     know old gdb releases' documentation should make this clear,
>     but I'd be surprised if it's really clear enough to write an
>     implementation from.

This is true, I would already have a hard time write an MI protocol
implementation. I really think at least having the differences from the
last protocol would be a big help. At least that way, I could start with
MI3, and then when MI4 comes around, I could see a list of
incompatibilites. The real answer to me would be to have a list of all
the MI protocols documented in every release. Especially since they are
backwards compatible, and GDB still supports them. Maybe things like
have the MI commands list what version of MI they appeared in.

>  3. Is there a guarantee that old MI interfaces will be supported?
>     Or will we wake up to find gdb 6.3 has deprecated, e.g. MI1, and
>     scheduled it for purging?

This is what I need to know.

Thanks,
Bob Rossi

GDB/MI snapshots between major release's

[Bob Rossi]

Hi,

To make things simple, I am separating some of my questions out into
several threads as Eli suggested. There are only a few, and I hope they
are not to annoying.

How should front end developers deal with snapshots of GDB, that are
taken between major versions of GDB. Several distributions
do this and I don't think most front end's would be capable of dealing
with a GDB in this state. In this state, GDB says it is MI3 but outputs commands
in the MI4 style (because version hasn't been bumped yet) or vice versa.
Does this even happen?

Here is my take, since Eli stated that MI is backwards compatible, I
think the version number should be bumped right before the release. This
way, any snapshot of GDB will get the last major version of the MI
protocol that was publically released and supported. Does this sound
correct?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> How should front end developers deal with snapshots of GDB, that are
> taken between major versions of GDB. Several distributions

I think you're overthinking this.  if some version of gdb doesn't
fulfill the compatibility guarantee, then it's a bug in gdb, and
it shouldn't be hard to have the user install a gdb version
without the bug.  at worst, you can supply your own version of
gdb.  few things depend on specific gdb version.  it's not a big
deal to have multiple gdb versions installed.  source code
availability means you don't have to wait for the gdb cabal to
fix it, and the cabal is generally eager to take reasonable
bugfixes, which solves the long-term problem.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Sun, Oct 03, 2004 at 11:00:30AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > How should front end developers deal with snapshots of GDB, that are
> > taken between major versions of GDB. Several distributions
> 
> I think you're overthinking this.  if some version of gdb doesn't
> fulfill the compatibility guarantee, then it's a bug in gdb, and
> it shouldn't be hard to have the user install a gdb version
> without the bug.  at worst, you can supply your own version of
> gdb.  few things depend on specific gdb version.  it's not a big
> deal to have multiple gdb versions installed.  source code
> availability means you don't have to wait for the gdb cabal to
> fix it, and the cabal is generally eager to take reasonable
> bugfixes, which solves the long-term problem.

I would say that I am not overthinking it, I am simply thinking about
it. I want to make sure that CVS snapshots will support a valid MI
interface. Major distro's use these snapshots, and I would like to have
compatibility with them.

Bob Rossi

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Sun, Oct 03, 2004 at 02:36:18PM -0400, Bob Rossi wrote:
> On Sun, Oct 03, 2004 at 11:00:30AM -0700, Felix Lee wrote:
> > Bob Rossi <bob@brasko.net>:
> > > How should front end developers deal with snapshots of GDB, that are
> > > taken between major versions of GDB. Several distributions
> > 
> > I think you're overthinking this.  if some version of gdb doesn't
> > fulfill the compatibility guarantee, then it's a bug in gdb, and
> > it shouldn't be hard to have the user install a gdb version
> > without the bug.  at worst, you can supply your own version of
> > gdb.  few things depend on specific gdb version.  it's not a big
> > deal to have multiple gdb versions installed.  source code
> > availability means you don't have to wait for the gdb cabal to
> > fix it, and the cabal is generally eager to take reasonable
> > bugfixes, which solves the long-term problem.
> 
> I would say that I am not overthinking it, I am simply thinking about
> it. I want to make sure that CVS snapshots will support a valid MI
> interface. Major distro's use these snapshots, and I would like to have
> compatibility with them.

So, use the last frozen MI version supported by that snapshot?

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Sun, Oct 03, 2004 at 02:40:36PM -0400, Daniel Jacobowitz wrote:
> On Sun, Oct 03, 2004 at 02:36:18PM -0400, Bob Rossi wrote:
> > On Sun, Oct 03, 2004 at 11:00:30AM -0700, Felix Lee wrote:
> > > Bob Rossi <bob@brasko.net>:
> > > > How should front end developers deal with snapshots of GDB, that are
> > > > taken between major versions of GDB. Several distributions
> > > 
> > > I think you're overthinking this.  if some version of gdb doesn't
> > > fulfill the compatibility guarantee, then it's a bug in gdb, and
> > > it shouldn't be hard to have the user install a gdb version
> > > without the bug.  at worst, you can supply your own version of
> > > gdb.  few things depend on specific gdb version.  it's not a big
> > > deal to have multiple gdb versions installed.  source code
> > > availability means you don't have to wait for the gdb cabal to
> > > fix it, and the cabal is generally eager to take reasonable
> > > bugfixes, which solves the long-term problem.
> > 
> > I would say that I am not overthinking it, I am simply thinking about
> > it. I want to make sure that CVS snapshots will support a valid MI
> > interface. Major distro's use these snapshots, and I would like to have
> > compatibility with them.
> 
> So, use the last frozen MI version supported by that snapshot?

Yes, that's what I was thinking also. Is that what is expected? Finally,
this idea along with this new command line argument,
http://sources.redhat.com/ml/gdb/2004-10/msg00027.html

I would be able to figure out the last stable version of MI is and use it,
even when it is a CVS snapshot. 

Does this sound correct? I figure the command line argument
--mi-protocols will only output the versions of MI that were released as
stable ( for a release ).

This would solve several important problem for me.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I would say that I am not overthinking it, I am simply thinking about
> it. I want to make sure that CVS snapshots will support a valid MI
> interface. Major distro's use these snapshots, and I would like to have
> compatibility with them.

the gdb testsuite has tests that exercise the MI versions.
'successfully passing the MI tests' is a form of compatibility
guarantee.  if the existing tests aren't a strong enough
guarantee, then new tests can be added.  the bigger problem is
insufficient manpower to fix known failures.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Sun, Oct 03, 2004 at 12:35:47PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I would say that I am not overthinking it, I am simply thinking about
> > it. I want to make sure that CVS snapshots will support a valid MI
> > interface. Major distro's use these snapshots, and I would like to have
> > compatibility with them.
> 
> the gdb testsuite has tests that exercise the MI versions.
> 'successfully passing the MI tests' is a form of compatibility
> guarantee.  if the existing tests aren't a strong enough
> guarantee, then new tests can be added.  

This is great news!

> the bigger problem is
> insufficient manpower to fix known failures.

Is there a list of these known failures or problems?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> Is there a list of these known failures or problems?

here's one list, for redhat-8.0
    http://www.shout.net/~mec/sunday/current/
for mi tests, search for the string 'gdb.mi'
--

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> OK, at first I don't like this idea for several reasons. It seems to me
> that with this approach you could end up releasing GDB 6.0 with MI
> version 1 and GDB 6.1 with MI version 5. Meaning that there could be
> several versions of MI revisions between one major release.
> It seems that you would have to run the testsuite on every incompatible
> change that the MI protocol goes through, including several for only one
> release. Also, a front end would have to understand all of these
> revisions in hopes of working with the most recent GDB (CVS snapshots).

I really don't understand what's the problem you're trying to
solve.  MI doesn't change often.  and even if it did, each
version of MI has separate tests in the testsuite.  a front-end
doesn't have to understand any MI changes if it doesn't want to,
if it understands MI5, it should invoke gdb with
--interpreter=mi5.

if the gdb doesn't understand mi5, then you can try fallback to
--interpreter=mi1.  I don't see much benefit to a front-end
knowing more than two versions of MI, and most of the time
knowing just one should be adequate.

if your front-end tries mi5 and fails because gdb has made an
incompatible change to mi5, then that's a bug in gdb, and if that
bug gets exposed in a user version of gdb, the answer is 'your
gdb has a bug, install a non-buggy one'.

what's your failure scenario?
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 07:59:21AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > OK, at first I don't like this idea for several reasons. It seems to me
> > that with this approach you could end up releasing GDB 6.0 with MI
> > version 1 and GDB 6.1 with MI version 5. Meaning that there could be
> > several versions of MI revisions between one major release.
> > It seems that you would have to run the testsuite on every incompatible
> > change that the MI protocol goes through, including several for only one
> > release. Also, a front end would have to understand all of these
> > revisions in hopes of working with the most recent GDB (CVS snapshots).
> 
> I really don't understand what's the problem you're trying to
> solve.  MI doesn't change often.  

I'm not interested in how often it changes at all. I'm interested in
the fact that it does change.

> a front-end
> doesn't have to understand any MI changes if it doesn't want to,
> if it understands MI5, it should invoke gdb with
> --interpreter=mi5.

You are correct, a front end doesn't have to do anything if it doesn't
want to. 

However, I want my front end to understand every MI protocol and I think
that this is OK with the GDB people. Is it a goal of GDB to make sure
that front ends can not understand every protocol? I highly doubt it.

> if the gdb doesn't understand mi5, then you can try fallback to
> --interpreter=mi1.  I don't see much benefit to a front-end
> knowing more than two versions of MI, and most of the time
> knowing just one should be adequate.

Of course there is a benefit. A front end should know every version of
the MI protocol. Since it will know all of the protocols, it could work
with a given GDB using the latest/greatest protocol that that GDB
supported.

> if your front-end tries mi5 and fails because gdb has made an
> incompatible change to mi5, then that's a bug in gdb, and if that
> bug gets exposed in a user version of gdb, the answer is 'your
> gdb has a bug, install a non-buggy one'.
> 
> what's your failure scenario?

I don't know what you are talking about here. Can you see that I'm
interested in having a new front end start any GDB with it's newest MI
protocol?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> I don't know what you are talking about here. Can you see that I'm
> interested in having a new front end start any GDB with it's newest MI
> protocol?

why isn't that possible now?  what situation makes it difficult
to do that?
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 09:04:55AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > I don't know what you are talking about here. Can you see that I'm
> > interested in having a new front end start any GDB with it's newest MI
> > protocol?
> 
> why isn't that possible now?  what situation makes it difficult
> to do that?

My original posting has the problem that I am confronting,

   How should front end developers deal with snapshots of GDB, that are
   taken between major versions of GDB. Several distributions
   do this and I don't think most front end's would be capable of dealing
   with a GDB in this state. In this state, GDB says it is MI3 but outputs commands
   in the MI4 style (because version hasn't been bumped yet) or vice versa.
   Does this even happen?

With the information I have now, here is the problem. A snapshot of GDB
will say that it is at MI4, although, it is really at some
developmental version. So, I need to get from GDB that MI4 is not an
official protocol, and that I should be using MI3 to communicate with
it. This seems to be the only problem.

This is why I am suggesting the new command line switch, which according
to the case above, would produce,

gdb --mi-protocols
mi1
mi2
mi3

However, Eli suggested making an MI command that does this, that is
still up for debate I guess.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> With the information I have now, here is the problem. A snapshot of GDB
> will say that it is at MI4, although, it is really at some
> developmental version.

does that ever happen?  if gdb says it supports MI4 but it
doesn't really, then it's lying, and that's a bug.  I think it's
unreasonable to expect a front-end to have workarounds for every
gdb bug.  the best answer is often 'get a gdb without the bug'.
it might be reasonable to have workarounds for bugs in gdb
versions that are widely deployed, and that can be handled on a
case-by-case basis.

I don't have any objection to an --mi-protocols switch, but it
seems to me that it isn't really needed by front-ends.  one
simple strategy is to just try each mi version you know until you
find one that works.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 11:12:01AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > With the information I have now, here is the problem. A snapshot of GDB
> > will say that it is at MI4, although, it is really at some
> > developmental version.
> 
> does that ever happen?  if gdb says it supports MI4 but it
> doesn't really, then it's lying, and that's a bug.  I think it's
> unreasonable to expect a front-end to have workarounds for every
> gdb bug.  the best answer is often 'get a gdb without the bug'.
> it might be reasonable to have workarounds for bugs in gdb
> versions that are widely deployed, and that can be handled on a
> case-by-case basis.

Felix, I think either I am wrong here about how GDB bumps it's version
numbers, or you do not understand what I am talking about. I am often
blamed for not explaining things clearly, so here it goes again.

While GDB is between versions, it will bump it's MI protocol number by
one if there is an MI backwards compatible issue. Right? (this was
stated by Mark Kettenis )

OK, so, if you get snapshots of GDB during it's development, the newly
bumped version of the MI protocol is *not* a valid protocol. It is a
protocol under development that will become an official protocol only
after a release is made. Here is a simple example, 
T1 GDB 7.0 has MI10 (official)
T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
T4 GDB 7.1 has MI11 (official)

The assertion is GDB is not necessarily talking an official MI protocol 
until the release.

If I get a snapshot of GDB when in development, between time T2 and T3,
then my front end will not work with GDB's MI11 protocol. It will only
work with MI10. So, I need to find out from GDB what version's it will
officially support, and then the issue of working with GDB snapshots
will go away for ever (hopefully). 


> I don't have any objection to an --mi-protocols switch, but it
> seems to me that it isn't really needed by front-ends.  one
> simple strategy is to just try each mi version you know until you
> find one that works.

GDB currently says that it supports MI11 between times T2 and T3,
however, this is not true. It is a developmental version, that does not
conform to any specific version of the MI protocol.

Do you see the problem I am describing?

Here is debian testing ( the first system I tried ).
$ gdb --version
GNU gdb 2002-04-01-cvs

We don't have to have all the package maintainers give a formal snapshot
of GDB, we just need to make front end's understand all of the official
protocols that a given GDB supports.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> T1 GDB 7.0 has MI10 (official)
> T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
> T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
> T4 GDB 7.1 has MI11 (official)

why would that happen?  I expect 'create a new MI version' to be
basically an atomic change.  like, someone experiments with MI11
on a branch, then merges it into the trunk when it's stable and
tests reasonable cleanly.

if the incompatible change is simple enough to be done in the
trunk, then updating the version and the testsuite should be part
of the same commit.
--

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > T1 GDB 7.0 has MI10 (official)
> > T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
> > T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
> > T4 GDB 7.1 has MI11 (official)
> 
> why would that happen?  I expect 'create a new MI version' to be
> basically an atomic change.  like, someone experiments with MI11
> on a branch, then merges it into the trunk when it's stable and
> tests reasonable cleanly.
> 
> if the incompatible change is simple enough to be done in the
> trunk, then updating the version and the testsuite should be part
> of the same commit.

Except that's not how it's done.  Someone else explained how the
version numbers work upthread - the latest one may be evolving.

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > T1 GDB 7.0 has MI10 (official)
> > T2 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X1 )
> > T3 GDB 7.0-CVS has MI11 (unofficial, because of MI incompatible change X2 )
> > T4 GDB 7.1 has MI11 (official)
> 
> why would that happen?  I expect 'create a new MI version' to be
> basically an atomic change.  like, someone experiments with MI11
> on a branch, then merges it into the trunk when it's stable and
> tests reasonable cleanly.

This is frustrating to me, does anyone understand the problem that I am
describing? Maybe it could be said in a better way.

Basically, a given GDB (from an official release) supports several MI protocols.
A given GDB from a CVS snapshot supports several MI protocols and 1
unsupported protocol.

The 1 unsupported protocol is the problem. 

During development, the first incompatible change forces the MI version
number to be bumped. Every incompatible change after that does not
effect the MI version number. Only after the release can the number be
bumped again (as far as I understand it).

Once the development GDB reaches maturity and becomes an official release, 
the development protocol becomes an official protocol. That new MI protocol could
consist of say 10 incompatible changes with it's predecessor.

Any CVS snapshot after the first incompatible change (version bump) and
before the release will have GDB talking an MI protocol that is not
supported by anyone. It is a development protocol that should never be
used.

I am saying that I need to know if GDB is communicating with one of
these development MI protocols, because I want to use the last official
MI protocol, not a development MI protocol.

Do you understand?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Fabian Cenedese]

At 17:27 04.10.2004 -0400, Bob Rossi wrote:
>On Mon, Oct 04, 2004 at 01:53:57PM -0700, Felix Lee wrote:
>> why would that happen?  I expect 'create a new MI version' to be
>> basically an atomic change.  like, someone experiments with MI11
>> on a branch, then merges it into the trunk when it's stable and
>> tests reasonable cleanly.
>
>This is frustrating to me, does anyone understand the problem that I am
>describing? Maybe it could be said in a better way.

I do, though I haven't a solution either.

>Basically, a given GDB (from an official release) supports several MI protocols.
>A given GDB from a CVS snapshot supports several MI protocols and 1
>unsupported protocol.
>
>The 1 unsupported protocol is the problem. 

One thing that could be added is that -i mi doesn't mean the last one (like mi2 now)
but the last official one. So if there will be a mi3 in progress mi will still select mi2.
Like that you will always be using the last stable protocol. And others can work
with the development version by calling -i mi3. But that won't solve your problem
of knowing what mi version the last stable really is.

>During development, the first incompatible change forces the MI version
>number to be bumped. Every incompatible change after that does not
>effect the MI version number. Only after the release can the number be
>bumped again (as far as I understand it).

The release would be the point where -i mi changes from mi2 to mi3.

>I am saying that I need to know if GDB is communicating with one of
>these development MI protocols, because I want to use the last official
>MI protocol, not a development MI protocol.

To take your example:

gdb --mi-protocols
 mi1
*mi2
 mi3

which means that mi2 is the default (and therefore last stable) mi version. Like
that you get all the necessary info about available and stable versions at once.

bye  Fabi

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Tue, 05 Oct 2004 08:59:32 +0200
> From: Fabian Cenedese <Cenedese@indel.ch>
> 
> One thing that could be added is that -i mi doesn't mean the last
> one (like mi2 now) but the last official one. So if there will be a
> mi3 in progress mi will still select mi2.  Like that you will always
> be using the last stable protocol. And others can work with the
> development version by calling -i mi3. But that won't solve your
> problem of knowing what mi version the last stable really is.

Knowing which MI version is the last stable one is important, but it's
a separate issue.  Do we all agree that for official GDB releases the
problem of MI versions is solved by the features that we already have,
or do someone think that a feature that reports supported MI versions
is still needed even for the official releases?  Let's solve the
situation with official releases first, and get to the development
versions later.

As for the problem with development versions, I think it's part of a
larger problem: how can one know that a certain snapshot is stable
enough to make it available to users?  The stability of MI is a
relatively small aspect of this larger problem, and there's always the
solution suggested by Jason (I think): use the latest stable version
of MI, the one released with the last official GDB version.

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Tue, Oct 05, 2004 at 11:06:59AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 05 Oct 2004 08:59:32 +0200
> > From: Fabian Cenedese <Cenedese@indel.ch>
> > 
> > One thing that could be added is that -i mi doesn't mean the last
> > one (like mi2 now) but the last official one. So if there will be a
> > mi3 in progress mi will still select mi2.  Like that you will always
> > be using the last stable protocol. And others can work with the
> > development version by calling -i mi3. But that won't solve your
> > problem of knowing what mi version the last stable really is.
> 
> Knowing which MI version is the last stable one is important, but it's
> a separate issue.  Do we all agree that for official GDB releases the
> problem of MI versions is solved by the features that we already have,
> or do someone think that a feature that reports supported MI versions
> is still needed even for the official releases?  Let's solve the
> situation with official releases first, and get to the development
> versions later.

I didn't think there was a problem with using a GDB stable version MI
protocol. This I expected to work the way the documentation described.
I started this thread to figure out how to deal with development
versions which were a side effect of using CVS snapshot's of GDB.

However, I still think that it is necessary to know the supported MI
versions, if the GDB is a stable or a development version.
I started the thread, 
"probing GDB for MI versions"
http://sources.redhat.com/ml/gdb/2004-10/msg00027.html
to resolve this issue (you obviously already know about this, but other
people might not)

It is a requirement of the front end to figure out the highest common MI
protocol that both it and GDB speek. This needs to be done before any
communication can occur between GDB and the front end.

> As for the problem with development versions, I think it's part of a
> larger problem: how can one know that a certain snapshot is stable
> enough to make it available to users?  

I do not know how to answer this question, and I assume that using a CVS
snapshot means that the MI protocol is under development and that it
should not be used.

> The stability of MI is a
> relatively small aspect of this larger problem, and there's always the
> solution suggested by Jason (I think): use the latest stable version
> of MI, the one released with the last official GDB version.

This seems like a good idea to me. I think that we have come to the
conclusion that the cutting edg MI protocol that comes with a CVS snapshots 
of GDB should not be used. It is essential that the front end can figure
out the last stable version of MI that was supported.

Bob Rossi

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> If at some point, GDB decides not to honor MI2 anymore, I need to make
> sure that I know that. If my front end only supports MI2, and GDB
> supports only MI3, than the function you are suggesting will not be good
> enough for me.

I think there's no chance that situation will occur.

if sometime in the future gdb stops honoring MI7, then presumably
it honors a newer version, MI21.  since your front-end knows
about MI21, then you don't care that MI7 is gone.  so that's not
a problem.

if MI7 is the only version that a front-end knows, then that's a
strong argument against removing MI7, so that's not a problem
either.
--

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Wed, Oct 06, 2004 at 10:12:53AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > If at some point, GDB decides not to honor MI2 anymore, I need to make
> > sure that I know that. If my front end only supports MI2, and GDB
> > supports only MI3, than the function you are suggesting will not be good
> > enough for me.
> 
> I think there's no chance that situation will occur.
> 
> if sometime in the future gdb stops honoring MI7, then presumably
> it honors a newer version, MI21.  since your front-end knows
> about MI21, then you don't care that MI7 is gone.  so that's not
> a problem.
> 
> if MI7 is the only version that a front-end knows, then that's a
> strong argument against removing MI7, so that's not a problem
> either.

Actually, I doubt GDB will continue to support old MI versions
indefinitely.  It may be very hard.  For instance, at some point we may
report multiple events to the front end at once (from different
threads); or multiple addresses associated with a breakpoint.  Faking
an old interface will not be worth the trouble.

I expect there will be points at which front ends will have to be
updated to talk to a new GDB.

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Felix Lee]

Daniel Jacobowitz <drow@false.org>:
> Actually, I doubt GDB will continue to support old MI versions
> indefinitely.  It may be very hard.  For instance, at some point we may
> report multiple events to the front end at once (from different
> threads); or multiple addresses associated with a breakpoint.  Faking
> an old interface will not be worth the trouble.

> I expect there will be points at which front ends will have to be
> updated to talk to a new GDB.

right.  if it's too hard to support an old MI, any front-end
using the old MI will have the wrong model of interaction with
gdb, so the front-end will need substantial work to talk to the
new gdb no matter what, so that's not a problem either.
--

Re: GDB/MI snapshots between major release's

[Felix Lee]

Bob Rossi <bob@brasko.net>:
> You obviously not understanding the point here. I can not even get my
> front end to the point where it can look at the command. The reason is,
> I can not *PARSE* the command. 

mostly, I don't understand why you feel you need to parse a
command before understanding it, when the command is something
simple like a 'who are you?' challenge/response.  most programs
that can speak to different clients will do some dynamic
adaptation of protocol based on interaction with the client.
it's not clear to me why you want to do it differently.

> Therefor, I don't have a parse tree, and can not even begin to
> understand what MI output command GDB just sent to me.

this seems to be the miscommunication going on.  I don't think I
need a parse tree to begin understanding output, and it's not
clear to me what programming model you're using that makes it
hard to do simple output recognition without a parse tree.
--

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 11:30:20AM -0700, Felix Lee wrote:
> Bob Rossi <bob@brasko.net>:
> > You obviously not understanding the point here. I can not even get my
> > front end to the point where it can look at the command. The reason is,
> > I can not *PARSE* the command. 
> 
> mostly, I don't understand why you feel you need to parse a
> command before understanding it, when the command is something
> simple like a 'who are you?' challenge/response.  most programs
> that can speak to different clients will do some dynamic
> adaptation of protocol based on interaction with the client.
> it's not clear to me why you want to do it differently.
> 
> > Therefor, I don't have a parse tree, and can not even begin to
> > understand what MI output command GDB just sent to me.
> 
> this seems to be the miscommunication going on.  I don't think I
> need a parse tree to begin understanding output, and it's not
> clear to me what programming model you're using that makes it
> hard to do simple output recognition without a parse tree.
> --

It's simply incorrect in my view to add the command to the MI command
set if no one expects you to use MI to use it. This is wierd.

I want to be able to use my MI parser's to read the MI protocol.

Bob Rossi

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Sun, 3 Oct 2004 12:39:18 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> Here is my take, since Eli stated that MI is backwards compatible, I
> think the version number should be bumped right before the release.

The MI number should be bumped when an incompatibility is introduced
on purpose, i.e. at the very moment when we decide to start a new MI
version.

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 3 Oct 2004 12:39:18 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > Here is my take, since Eli stated that MI is backwards compatible, I
> > think the version number should be bumped right before the release.
> 
> The MI number should be bumped when an incompatibility is introduced
> on purpose, i.e. at the very moment when we decide to start a new MI
> version.

OK, at first I don't like this idea for several reasons. It seems to me
that with this approach you could end up releasing GDB 6.0 with MI
version 1 and GDB 6.1 with MI version 5. Meaning that there could be
several versions of MI revisions between one major release.
It seems that you would have to run the testsuite on every incompatible
change that the MI protocol goes through, including several for only one
release. Also, a front end would have to understand all of these
revisions in hopes of working with the most recent GDB (CVS snapshots).

I have a suggestion, although I don't know how much it helps. I propose
that GDB changes the MI version once for every major release. It
documents the changes so that front end developers can update there
protocols appropriately from the last release. Finally, if the user
starts GDB like --interpreter=mi, it would actually give the current
development version of MI which is unsupported officially. Then the
front ends would have to query GDB for the officially supported released
protocols, and start GDB with the newest one they support.

Could this work well with the GDB team?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Mark Kettenis]

   Date: Mon, 4 Oct 2004 09:19:06 -0400
   From: Bob Rossi <bob@brasko.net>

   On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
   > > Date: Sun, 3 Oct 2004 12:39:18 -0400
   > > From: Bob Rossi <bob@brasko.net>
   > > 
   > > Here is my take, since Eli stated that MI is backwards compatible, I
   > > think the version number should be bumped right before the release.
   > 
   > The MI number should be bumped when an incompatibility is introduced
   > on purpose, i.e. at the very moment when we decide to start a new MI
   > version.

   OK, at first I don't like this idea for several reasons. It seems to me
   that with this approach you could end up releasing GDB 6.0 with MI
   version 1 and GDB 6.1 with MI version 5. Meaning that there could be
   several versions of MI revisions between one major release.

Of course not.  We'd bump the MI version on the first incompatible
change after a release, but we wouldn't bump it again until after the
next release.  It's highly unlikely that we'd have to bump the MI
version for a patch release, except when there's a need to fix a
critical bug in the MI interface.  Yes, GDB 6.1 could be released with
MI version 2, 6.2, 6.3 with MI version 3, GDB 6.4 with MI version 4
and GDB 7.0 with MI version 5.  But since we aim for stability of the
MI interface, even that would be unlikely.

   It seems that you would have to run the testsuite on every incompatible
   change that the MI protocol goes through, including several for only one
   release. Also, a front end would have to understand all of these
   revisions in hopes of working with the most recent GDB (CVS snapshots).

In the end there will be no hope for a frontend to be compatible with
each and every CVS snapshot that's made.  If we go through the
development process we might add several features between two
releases.  All we can guarantee is that once we make an official GDB
release with a certain version of MI, that version of MI will never
change again, and will be supported in the next X GDB releases.

Seems like your problem is that various Linux distribution come with
their own hacked versions of GDB that do not correspond to an official
release.  Those distributions are not doing proper release management.
You should blame them, not the GDB developers.  Or you should tell
your users to use an OS with proper release management like *BSD ;-).

   I have a suggestion, although I don't know how much it helps. I propose
   that GDB changes the MI version once for every major release. It
   documents the changes so that front end developers can update there
   protocols appropriately from the last release. Finally, if the user
   starts GDB like --interpreter=mi, it would actually give the current
   development version of MI which is unsupported officially. Then the
   front ends would have to query GDB for the officially supported released
   protocols, and start GDB with the newest one they support.

   Could this work well with the GDB team?

No.

Mark

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 05:33:54PM +0200, Mark Kettenis wrote:
>    Date: Mon, 4 Oct 2004 09:19:06 -0400
>    From: Bob Rossi <bob@brasko.net>
> 
>    On Mon, Oct 04, 2004 at 06:57:35AM +0200, Eli Zaretskii wrote:
>    > > Date: Sun, 3 Oct 2004 12:39:18 -0400
>    > > From: Bob Rossi <bob@brasko.net>
>    > > 
>    > > Here is my take, since Eli stated that MI is backwards compatible, I
>    > > think the version number should be bumped right before the release.
>    > 
>    > The MI number should be bumped when an incompatibility is introduced
>    > on purpose, i.e. at the very moment when we decide to start a new MI
>    > version.
> 
>    OK, at first I don't like this idea for several reasons. It seems to me
>    that with this approach you could end up releasing GDB 6.0 with MI
>    version 1 and GDB 6.1 with MI version 5. Meaning that there could be
>    several versions of MI revisions between one major release.
> 
> Of course not.  We'd bump the MI version on the first incompatible
> change after a release, but we wouldn't bump it again until after the
> next release.  It's highly unlikely that we'd have to bump the MI
> version for a patch release, except when there's a need to fix a
> critical bug in the MI interface.  Yes, GDB 6.1 could be released with
> MI version 2, 6.2, 6.3 with MI version 3, GDB 6.4 with MI version 4
> and GDB 7.0 with MI version 5.  But since we aim for stability of the
> MI interface, even that would be unlikely.

OK, this is good news. So basically, even thought the MI version is
bumped it is still not official. Meaning, at that point, if I updated my
front end to be compatible with the new MI protocol version, there could
still be another incompatible change before the release. Meaning, I
would have to wait for the release to get the use out of that new
version. This is OK with me as long as,

   - I can have the --mi-protocols command line switch that tells me 
   what version of GDB/MI protocol is officially supported.

   - This command line switch only has MI protocols added to it when the 
   MI protocols become official ( for a release )

>    It seems that you would have to run the testsuite on every incompatible
>    change that the MI protocol goes through, including several for only one
>    release. Also, a front end would have to understand all of these
>    revisions in hopes of working with the most recent GDB (CVS snapshots).
> 
> In the end there will be no hope for a frontend to be compatible with
> each and every CVS snapshot that's made.  

Agreed, and I am learning that it would be wise to stay away from this
idea. It seems better that the front end understand somehow that the
current version is not official (CVS snapshot) and it should work with
the last official release.

> If we go through the
> development process we might add several features between two
> releases.  All we can guarantee is that once we make an official GDB
> release with a certain version of MI, that version of MI will never
> change again, and will be supported in the next X GDB releases.

This is perfect. Is this your view or the view of GDB/MI's maintainers
also?

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Mon, 4 Oct 2004 11:58:05 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: eliz@gnu.org, gdb@sources.redhat.com
> 
> OK, this is good news. So basically, even thought the MI version is
> bumped it is still not official. Meaning, at that point, if I updated my
> front end to be compatible with the new MI protocol version, there could
> still be another incompatible change before the release. Meaning, I
> would have to wait for the release to get the use out of that new
> version. This is OK with me as long as,
> 
>    - I can have the --mi-protocols command line switch that tells me 
>    what version of GDB/MI protocol is officially supported.
> 
>    - This command line switch only has MI protocols added to it when the 
>    MI protocols become official ( for a release )

We could do that, but I still think an MI command is a better vehicle
for such a feature.

> Is this your view or the view of GDB/MI's maintainers also?

I'm not an MI maintainer, but I fully agree with Mark, FWIW.

Re: GDB/MI snapshots between major release's

[Daniel Jacobowitz]

On Tue, Oct 05, 2004 at 11:14:44AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 4 Oct 2004 11:58:05 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: eliz@gnu.org, gdb@sources.redhat.com
> > 
> > OK, this is good news. So basically, even thought the MI version is
> > bumped it is still not official. Meaning, at that point, if I updated my
> > front end to be compatible with the new MI protocol version, there could
> > still be another incompatible change before the release. Meaning, I
> > would have to wait for the release to get the use out of that new
> > version. This is OK with me as long as,
> > 
> >    - I can have the --mi-protocols command line switch that tells me 
> >    what version of GDB/MI protocol is officially supported.
> > 
> >    - This command line switch only has MI protocols added to it when the 
> >    MI protocols become official ( for a release )
> 
> We could do that, but I still think an MI command is a better vehicle
> for such a feature.

I think using a command line switch makes sense.  You're going to have
to restart GDB to change MI protocols anyway, so why force the user to
go into MI?

I also like the idea of listing non-MI (which right now means annotate)
protocols in the same output.

-- 
Daniel Jacobowitz

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Tue, Oct 05, 2004 at 10:07:36AM -0400, Daniel Jacobowitz wrote:
> On Tue, Oct 05, 2004 at 11:14:44AM +0200, Eli Zaretskii wrote:
> > > Date: Mon, 4 Oct 2004 11:58:05 -0400
> > > From: Bob Rossi <bob@brasko.net>
> > > Cc: eliz@gnu.org, gdb@sources.redhat.com
> > > 
> > > OK, this is good news. So basically, even thought the MI version is
> > > bumped it is still not official. Meaning, at that point, if I updated my
> > > front end to be compatible with the new MI protocol version, there could
> > > still be another incompatible change before the release. Meaning, I
> > > would have to wait for the release to get the use out of that new
> > > version. This is OK with me as long as,
> > > 
> > >    - I can have the --mi-protocols command line switch that tells me 
> > >    what version of GDB/MI protocol is officially supported.
> > > 
> > >    - This command line switch only has MI protocols added to it when the 
> > >    MI protocols become official ( for a release )
> > 
> > We could do that, but I still think an MI command is a better vehicle
> > for such a feature.
> 
> I think using a command line switch makes sense.  You're going to have
> to restart GDB to change MI protocols anyway, so why force the user to
> go into MI?
> 
> I also like the idea of listing non-MI (which right now means annotate)
> protocols in the same output.

Have we come to a resolution that a command like this is necessary? 

I basically need it to query GDB to determine what MI versions it
officially supports.

It would satisfy my needs from GDB, but what about others?

Bob Rossi

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Tue, 5 Oct 2004 10:07:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Bob Rossi <bob@brasko.net>, kettenis@gnu.org, gdb@sources.redhat.com
> 
> I think using a command line switch makes sense.  You're going to have
> to restart GDB to change MI protocols anyway, so why force the user to
> go into MI?

First, it is possible that when the front end knows which MI version
is the last stable one, it will not need to restart GDB, but just
arrange for the appropriate parser to be used for the rest of the
session.

And second, even if you do need to restart, it makes sense to have
this command in the MI so that the same parser could be used to do
the job of finding the MI version(s) as well, instead of having a
special code that parses the ouput of a command-line option.

A downside of the command-line option that I very much don't like is
that command-line options are mainly for the human users and are
documented in a special section that describes how to run GDB, not how
to use the MI interpreter.

> I also like the idea of listing non-MI (which right now means annotate)
> protocols in the same output.

Does some front end need that?  If not, why introduce unneeded
generalizations?  I actually think that the output of the feature we
are discussing needs to be a single string: the latest version of MI
supported by this GDB that is known to be stable.  Given that info,
the front end should be able to figure out all the stable versions it
can use: they are those whose version numbers are below the latest
stable one.

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 12:15:40PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 5 Oct 2004 10:07:36 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Bob Rossi <bob@brasko.net>, kettenis@gnu.org, gdb@sources.redhat.com
> > 
> > I think using a command line switch makes sense.  You're going to have
> > to restart GDB to change MI protocols anyway, so why force the user to
> > go into MI?
> 
> First, it is possible that when the front end knows which MI version
> is the last stable one, it will not need to restart GDB, but just
> arrange for the appropriate parser to be used for the rest of the
> session.

This is not correct. The front end has parsers for different versions of
GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol
The front end *can not* start up GDB just by using -interpreter=mi
because it doesn't know what parser to use in this situation.
Can we agree on this point for starters?

This is why there needs to be a non-MI command to figure out what MI
versions the current GDB supports.

> A downside of the command-line option that I very much don't like is
> that command-line options are mainly for the human users and are
> documented in a special section that describes how to run GDB, not how
> to use the MI interpreter.

Yes, this is a downside, but I don't think your MI solution is quite
ready for use, however, maybe we could come up with something better
still.

> > I also like the idea of listing non-MI (which right now means annotate)
> > protocols in the same output.
> 
> Does some front end need that?  If not, why introduce unneeded
> generalizations?  

Yes, of course they do :)
xxgdb, ddd, gvd, ...
They all use annotations and they all assume annotate 1 is around. As
soon as you pull annotate 1, they will all have the same problem.

Emacs uses annotate 1, probably annotate 2 at some version and now
annotate 3 at some version. Also, I believe it's moving into the MI
realm .... what a mess ...

> I actually think that the output of the feature we
> are discussing needs to be a single string: the latest version of MI
> supported by this GDB that is known to be stable.  Given that info,
> the front end should be able to figure out all the stable versions it
> can use: they are those whose version numbers are below the latest
> stable one.

This is wrong. I *need* the output to have *all* the versions of MI that
the current GDB supports. I need this for a very very simple reason. I
need to make sure that my front ends that don't support the current
official release of GDB can start GDB in the highest mode it supports.

If at some point, GDB decides not to honor MI2 anymore, I need to make
sure that I know that. If my front end only supports MI2, and GDB
supports only MI3, than the function you are suggesting will not be good
enough for me.

Bob Rossi

Re: GDB/MI snapshots between major release's

[Eli Zaretskii]

> Date: Wed, 6 Oct 2004 07:27:03 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
> 
> > First, it is possible that when the front end knows which MI version
> > is the last stable one, it will not need to restart GDB, but just
> > arrange for the appropriate parser to be used for the rest of the
> > session.
> 
> This is not correct. The front end has parsers for different versions of
> GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol

In general, it won't, but for a very specific case of _a_single_command_,
it could very well do.  Obviously, we will need to agree to _never_ 
change the syntax of the output of that command once it is introduced,
but that is all we need to do to make sure _every_ MI parser henceforth
will understand that command's output.

> The front end *can not* start up GDB just by using -interpreter=mi
> because it doesn't know what parser to use in this situation.
> Can we agree on this point for starters?

Obviously, I disagree: if the syntax of what that command outputs does
not change, you should be able to use _any_ MI parser that knows about
this command; in particularly, the latest MI parser will do, so
invoking GDB with "-interpreter=mi" will solve the problem.  Can we
agree on this point?

> > > I also like the idea of listing non-MI (which right now means annotate)
> > > protocols in the same output.
> > 
> > Does some front end need that?  If not, why introduce unneeded
> > generalizations?  
> 
> Yes, of course they do :)
> xxgdb, ddd, gvd, ...
> They all use annotations and they all assume annotate 1 is around. As
> soon as you pull annotate 1, they will all have the same problem.

So how these front ends solve this problem now?

> > I actually think that the output of the feature we
> > are discussing needs to be a single string: the latest version of MI
> > supported by this GDB that is known to be stable.  Given that info,
> > the front end should be able to figure out all the stable versions it
> > can use: they are those whose version numbers are below the latest
> > stable one.
> 
> This is wrong. I *need* the output to have *all* the versions of MI that
> the current GDB supports. I need this for a very very simple reason. I
> need to make sure that my front ends that don't support the current
> official release of GDB can start GDB in the highest mode it supports.

I still don't see the problem, sorry.  Your front end surely knows (or
can know) what is the latest MI version it supports, right?  If so,
the following simple algorithm should do what you want:

  get the latest stable MI version from GDB, call it $mi-ver
  if $mi-ver is greater than N, the latest MI version supported by the front-end
    then restart GDB with "-interpreter=miN"
    else either set up to use the parser for $mi-ver
         or restart GDB with "-interpreter=mi"
  endif

What am I missing?

> If at some point, GDB decides not to honor MI2 anymore, I need to make
> sure that I know that. If my front end only supports MI2, and GDB
> supports only MI3, than the function you are suggesting will not be good
> enough for me.

If that happens, invoking GDB with "-interpreter=mi2" will exit with a
failure status and print an error message.  That should be enough for
the front end to say that it cannot work with such a GDB, if MI2 is
the only MI version the front end understands.  Still no problem that
I see; do you?

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 6 Oct 2004 07:27:03 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
> > 
> > > First, it is possible that when the front end knows which MI version
> > > is the last stable one, it will not need to restart GDB, but just
> > > arrange for the appropriate parser to be used for the rest of the
> > > session.
> > 
> > This is not correct. The front end has parsers for different versions of
> > GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol
> 
> In general, it won't, but for a very specific case of _a_single_command_,
> it could very well do.  

You obviously not understanding the point here. I can not even get my
front end to the point where it can look at the command. The reason is,
I can not *PARSE* the command. 

Here is a simple explanation that I have tried to discuss over and over.
   
   1. Each version of MI comes with a grammar.
   2. If the MI grammar changes between MI1 and MI2 then
   3. A parser is generated that understands the grammar for MI1
   4. A parser is generated that understands the grammar for MI2
   5. The parser for MI1 *will not parse* the output of MI2
   6. The parser for MI2 *will not parse* the output of MI1

Therefor, I don't have a parse tree, and can not even begin to
understand what MI output command GDB just sent to me. There is no
"specific case", where a front end could understand
"_a_single_command_".

This is a very simple issue I am discussing here and I expect people to
understand what I am saying.

> Obviously, we will need to agree to _never_ 
> change the syntax of the output of that command once it is introduced,
> but that is all we need to do to make sure _every_ MI parser henceforth
> will understand that command's output.

You are ready to guarentee that the MI output syntax (grammar) will
never change? This has nothing to do with the way the MI output command
lists the versions (field names, ... ).

> > The front end *can not* start up GDB just by using -interpreter=mi
> > because it doesn't know what parser to use in this situation.
> > Can we agree on this point for starters?
> 
> Obviously, I disagree: if the syntax of what that command outputs does
> not change, you should be able to use _any_ MI parser that knows about
> this command; in particularly, the latest MI parser will do, so
> invoking GDB with "-interpreter=mi" will solve the problem.  Can we
> agree on this point?

Are you saying that the MI output syntax wil never change? I doubt you
can make this promise.

> > > > I also like the idea of listing non-MI (which right now means annotate)
> > > > protocols in the same output.
> > > 
> > > Does some front end need that?  If not, why introduce unneeded
> > > generalizations?  
> > 
> > Yes, of course they do :)
> > xxgdb, ddd, gvd, ...
> > They all use annotations and they all assume annotate 1 is around. As
> > soon as you pull annotate 1, they will all have the same problem.
> 
> So how these front ends solve this problem now?

They assume annotate 1 is there, since it's 10 years old or so.
If it's not there, you probably will get random results.

> > > I actually think that the output of the feature we
> > > are discussing needs to be a single string: the latest version of MI
> > > supported by this GDB that is known to be stable.  Given that info,
> > > the front end should be able to figure out all the stable versions it
> > > can use: they are those whose version numbers are below the latest
> > > stable one.
> > 
> > This is wrong. I *need* the output to have *all* the versions of MI that
> > the current GDB supports. I need this for a very very simple reason. I
> > need to make sure that my front ends that don't support the current
> > official release of GDB can start GDB in the highest mode it supports.
> 
> I still don't see the problem, sorry.  Your front end surely knows (or
> can know) what is the latest MI version it supports, right?  If so,
> the following simple algorithm should do what you want:
> 
>   get the latest stable MI version from GDB, call it $mi-ver
>   if $mi-ver is greater than N, the latest MI version supported by the front-end
>     then restart GDB with "-interpreter=miN"
>     else either set up to use the parser for $mi-ver
>          or restart GDB with "-interpreter=mi"
>   endif
> 
> What am I missing?

You are missing elegance. It is a "first approach" to start GDB in every
MI mode from the highest one that the front end supports down. It would
be much more elegant to just ask GDB what versions of MI it supported.
As front ends scale, it could have to start GDB 10 times to figure out
what MI protocol it supports, even then, you wouldn't know if it was a
development protocol or not.

> > If at some point, GDB decides not to honor MI2 anymore, I need to make
> > sure that I know that. If my front end only supports MI2, and GDB
> > supports only MI3, than the function you are suggesting will not be good
> > enough for me.
> 
> If that happens, invoking GDB with "-interpreter=mi2" will exit with a
> failure status and print an error message.  That should be enough for
> the front end to say that it cannot work with such a GDB, if MI2 is
> the only MI version the front end understands.  Still no problem that
> I see; do you?

I understand your point here. I still think if we are going to put the
last officially released version, it would just be nice and easy to put
them all.

Thanks,
Bob Rossi

Re: GDB/MI snapshots between major release's

[Paul Koning]

>>>>> "Bob" == Bob Rossi <bob@brasko.net> writes:

 Bob> On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
 >> > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi
 >> <bob@brasko.net> > Cc: Daniel Jacobowitz <drow@false.org>,
 >> gdb@sources.redhat.com
 >> > 
 >> > > First, it is possible that when the front end knows which MI
 >> version > > is the last stable one, it will not need to restart
 >> GDB, but just > > arrange for the appropriate parser to be used
 >> for the rest of the > > session.
 >> > 
 >> > This is not correct. The front end has parsers for different
 >> versions of > GDB's MI protocol. The parser for MI2 will not work
 >> for the MI3 protocol
 >> 
 >> In general, it won't, but for a very specific case of
 >> _a_single_command_, it could very well do.

 Bob> You obviously not understanding the point here. I can not even
 Bob> get my front end to the point where it can look at the
 Bob> command. The reason is, I can not *PARSE* the command.

 Bob> Here is a simple explanation that I have tried to discuss over
 Bob> and over.
   
 Bob> 1. Each version of MI comes with a grammar.  2. If the MI
 Bob> grammar changes between MI1 and MI2 then 3. A parser is
 Bob> generated that understands the grammar for MI1 4. A parser is
 Bob> generated that understands the grammar for MI2 5. The parser for
 Bob> MI1 *will not parse* the output of MI2 6. The parser for MI2
 Bob> *will not parse* the output of MI1

I'm puzzled.  If MI2 is a superset of MI1, then the parser for MI2 by
definition will parse any string in MI1.  And generalizing, unless MI1
and MI2 have essentially nothing in common, I don't see how it can be
true that you cannot parse any command at all.

Just as in any protocol, you need version numbers to cope with the
situation where a new MIx is NOT just a superset of MI<x-1>.  But the
usual picture of protocol evolution is that those cases are not all
that common -- most evoluation creates supersets.

(And incidentally, a version numbering scheme would have to rely on
the restriction that a certain defined part of the protocol is
immutable, or at least allows no changes other than supersetting --
and that part conveys version information.)

     paul

Re: GDB/MI snapshots between major release's

[Bob Rossi]

On Wed, Oct 06, 2004 at 12:57:40PM -0400, Paul Koning wrote:
> >>>>> "Bob" == Bob Rossi <bob@brasko.net> writes:
> 
>  Bob> On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
>  >> > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi
>  >> <bob@brasko.net> > Cc: Daniel Jacobowitz <drow@false.org>,
>  >> gdb@sources.redhat.com
>  >> > 
>  >> > > First, it is possible that when the front end knows which MI
>  >> version > > is the last stable one, it will not need to restart
>  >> GDB, but just > > arrange for the appropriate parser to be used
>  >> for the rest of the > > session.
>  >> > 
>  >> > This is not correct. The front end has parsers for different
>  >> versions of > GDB's MI protocol. The parser for MI2 will not work
>  >> for the MI3 protocol
>  >> 
>  >> In general, it won't, but for a very specific case of
>  >> _a_single_command_, it could very well do.
> 
>  Bob> You obviously not understanding the point here. I can not even
>  Bob> get my front end to the point where it can look at the
>  Bob> command. The reason is, I can not *PARSE* the command.
> 
>  Bob> Here is a simple explanation that I have tried to discuss over
>  Bob> and over.
>    
>  Bob> 1. Each version of MI comes with a grammar.  2. If the MI
>  Bob> grammar changes between MI1 and MI2 then 3. A parser is
>  Bob> generated that understands the grammar for MI1 4. A parser is
>  Bob> generated that understands the grammar for MI2 5. The parser for
>  Bob> MI1 *will not parse* the output of MI2 6. The parser for MI2
>  Bob> *will not parse* the output of MI1
> 
> I'm puzzled.  If MI2 is a superset of MI1, then the parser for MI2 by
> definition will parse any string in MI1.  And generalizing, unless MI1
> and MI2 have essentially nothing in common, I don't see how it can be
> true that you cannot parse any command at all.
> 
> Just as in any protocol, you need version numbers to cope with the
> situation where a new MIx is NOT just a superset of MI<x-1>.  But the
> usual picture of protocol evolution is that those cases are not all
> that common -- most evoluation creates supersets.

Paul, you are almost correct, but you are not. The MIx is not a superset
of an MI<x-1>. They are incompatible. That is the problem.

Bob Rossi