Bob's MI objective

Bob's MI objective

[Andrew Cagney]

Bob, what's your overall objective here?  Perhaphs our lack of 
appreciation of your overriding goals is the reason that some (at least 
I) are feeling somewhat puzzled and confused.

Andrew

Re: Bob's MI objective

[Bob Rossi]

On Wed, Oct 06, 2004 at 04:12:32PM -0400, Andrew Cagney wrote:
> Bob, what's your overall objective here?  Perhaphs our lack of 
> appreciation of your overriding goals is the reason that some (at least 
> I) are feeling somewhat puzzled and confused.

I want an MI version named after myself, specifically 'gdb -i=bobmi'
No seriously,

I already have a front end that works off of GDB's annotate two feature.
I understand that the annotate two interface could be removed from GDB. 
I asked you a year or two ago to wait until MI is capable of replacing the
annotations. I personally wrote the two commands to MI
-file-list-exec-source-file
-file-list-exec-source-files
that make MI capable of replacing the annotations interface for front
ends that do not already know what files are involved in the users
applications. I appreciate your patience in this matter. I feel that I
have done my part in this matter to prove to you that I am interested
and involved with the MI interface evolving for small front ends. 

Now I am beginning to add the MI interface to my front end. I spent the
last few weeks looking at the grammar of the currently documented MI
output syntax. The documentation is incorrect, but mostly correct and I 
suggested some changes to it so that others could benefit.
I have come up with the rules and generated a parser that is capable of
parsing an MI output command. I would like to validate the output of
GDB's MI commands in the testsuite to prove to us all that every MI command 
obeys the protocol. This is something I am interested in doing for the 
benefit of all front end developers. Not just myself.

Now, my next objective is to figure these things,

   * I would like to know what GDB's policy is in regards to supporting old
     MI protocols.  ( I have received several opposing views on this )

   * I would like to ensure that my front end works well with snapshots
     of GDB. I do not want to work with the MI development protocol, I
     just want to work with the last officially supported protocol.

   * I would like to make sure that development protocols are never used
     by my front end and that I can figure out all of the officially 
     supported MI protocols that a given GDB supports.

By being able to understand the highest officially supported protocol
that both GDB and my front end understand is critical to me. I think it is 
safe to say that a front end needs to know the MI protocols that a given 
GDB supports. The way we get that info from GDB to the front end is the 
question in debate.

Thanks,
Bob Rossi

Re: Bob's MI objective

[Andrew Cagney]

>    * I would like to know what GDB's policy is in regards to supporting old
>      MI protocols.  ( I have received several opposing views on this )

By "supported" you're expecting?  I've stated what people developing GDB 
test, and given you a pretty clear hint as to the consequence.

I was wondering more of what your project and its goals were.

Andrew

Re: Bob's MI objective

[Bob Rossi]

On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote:
> >   * I would like to know what GDB's policy is in regards to supporting old
> >     MI protocols.  ( I have received several opposing views on this )
> 
> By "supported" you're expecting?  I've stated what people developing GDB 
> test, and given you a pretty clear hint as to the consequence.

Understood, here is what I am hoping for at a minimum. 

   * GDB supports at least 1 MI protocol for an official release. 
     Supporting multiple MI protocols would be better for me, but 
     not a requirement. If GDB could support multiple protocols it 
     would improve the chances of a given front end working with a
     given GDB.

   * GDB supports at least 1 MI protocol for a CVS snapshot. The
     development MI protocol is probably not suitable for front ends
     to work with, until it has stabilized and become official. So I am
     hoping that GDB supports the last officially supported MI protocol
     during it's development process, until the development protocol is
     ready to become stable.

> I was wondering more of what your project and its goals were.

CGDB is the front end I am working on, that said, I am actually not
doing all of the development of CGDB, just some of it.

I am focusing more on libtgdb. This is basically a library that is
capable of communicating with GDB with any interface that GDB supports.

It already supports annotate 2, now I am adding support for MI2. I would 
like to make this library support annotate 2, MI2, MI3, ...

Any front end developer can than take this library, and use it for there
front end, thus removing the burden of communicating with GDB. In
essence it is a libgdb that works with any GDB, not just one. The
library will be light weight, to the point where it can be used for many
applications, not just front ends ( embedded into tools that need simple
functionality like backtrace's, ... ).

I am interested in making this library part of the GDB distro, but
wouldn't suggest such a thing until it works. I think it would be good
if GDB distributed not only the MI interface and doco, but a reference
implementation of dealing with the protocols.

All of this said, I have a goal of making MI work and make sure that the
MI output commands actually adhere to the MI output syntax by testing
this in the testsuite. Probably the next step would be to make sure that
the MI input syntax follows the same rules. However, I have not made it
that far.

Do these goals seem reasonable?

Thanks,
Bob Rossi

Re: Bob's MI objective

[Andrew Cagney]

> On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote:
> 
>>>> >   * I would like to know what GDB's policy is in regards to supporting old
>>>> >     MI protocols.  ( I have received several opposing views on this )
>>
>>> 
>>> By "supported" you're expecting?  I've stated what people developing GDB 
>>> test, and given you a pretty clear hint as to the consequence.
> 
> 
> Understood, here is what I am hoping for at a minimum. 
> 
>    * GDB supports at least 1 MI protocol for an official release. 
>      Supporting multiple MI protocols would be better for me, but 
>      not a requirement. If GDB could support multiple protocols it 
>      would improve the chances of a given front end working with a
>      given GDB.

But by "support" what do you mean - even a dictionary definition.  GDB 
includes at least one MI implementation, but that says nothing about how 
well it is either implemented or supported.

>    * GDB supports at least 1 MI protocol for a CVS snapshot. The
>      development MI protocol is probably not suitable for front ends
>      to work with, until it has stabilized and become official. So I am
>      hoping that GDB supports the last officially supported MI protocol
>      during it's development process, until the development protocol is
>      ready to become stable.
> 
> 
>>> I was wondering more of what your project and its goals were.
> 
> 
> CGDB is the front end I am working on, that said, I am actually not
> doing all of the development of CGDB, just some of it.
> 
> I am focusing more on libtgdb. This is basically a library that is
> capable of communicating with GDB with any interface that GDB supports.

Why not instead help with libgdb, and the problem of being able to 
directly link in the debugger?

> It already supports annotate 2, now I am adding support for MI2. I would 
> like to make this library support annotate 2, MI2, MI3, ...
> 
> Any front end developer can than take this library, and use it for there
> front end, thus removing the burden of communicating with GDB. In
> essence it is a libgdb that works with any GDB, not just one. The
> library will be light weight, to the point where it can be used for many
> applications, not just front ends ( embedded into tools that need simple
> functionality like backtrace's, ... ).
> 
> I am interested in making this library part of the GDB distro, but
> wouldn't suggest such a thing until it works. I think it would be good
> if GDB distributed not only the MI interface and doco, but a reference
> implementation of dealing with the protocols.
> 
> All of this said, I have a goal of making MI work and make sure that the
> MI output commands actually adhere to the MI output syntax by testing
> this in the testsuite. Probably the next step would be to make sure that
> the MI input syntax follows the same rules. However, I have not made it
> that far.

Andrew

Re: Bob's MI objective

[Bob Rossi]

On Thu, Oct 07, 2004 at 03:17:45PM -0400, Andrew Cagney wrote:
> >On Wed, Oct 06, 2004 at 06:36:02PM -0400, Andrew Cagney wrote:
> >
> >>>>>   * I would like to know what GDB's policy is in regards to 
> >>>>supporting old
> >>>>>     MI protocols.  ( I have received several opposing views on this )
> >>
> >>>
> >>>By "supported" you're expecting?  I've stated what people developing GDB 
> >>>test, and given you a pretty clear hint as to the consequence.
> >
> >
> >Understood, here is what I am hoping for at a minimum. 
> >
> >   * GDB supports at least 1 MI protocol for an official release. 
> >     Supporting multiple MI protocols would be better for me, but 
> >     not a requirement. If GDB could support multiple protocols it 
> >     would improve the chances of a given front end working with a
> >     given GDB.
> 
> But by "support" what do you mean - even a dictionary definition.  GDB 
> includes at least one MI implementation, but that says nothing about how 
> well it is either implemented or supported.

That's a good question.

Well, by support I simply mean, GDB is officially saying that a
particular MI protocol is implemented as it should be, that it is tested
to make sure that it works to the best of the GDB developers knowledge and 
that it is safe to use by front ends.

I am assuming that MI protocols in development ( right after a version
bump, but before a major release ) is considered unsupported. By this I
guess I mean that it should not be used by front ends until it is
stable. Maybe a better word for "support" in this context is "stable".

> >   * GDB supports at least 1 MI protocol for a CVS snapshot. The
> >     development MI protocol is probably not suitable for front ends
> >     to work with, until it has stabilized and become official. So I am
> >     hoping that GDB supports the last officially supported MI protocol
> >     during it's development process, until the development protocol is
> >     ready to become stable.
> >
> >
> >>>I was wondering more of what your project and its goals were.
> >
> >
> >CGDB is the front end I am working on, that said, I am actually not
> >doing all of the development of CGDB, just some of it.
> >
> >I am focusing more on libtgdb. This is basically a library that is
> >capable of communicating with GDB with any interface that GDB supports.
> 
> Why not instead help with libgdb, and the problem of being able to 
> directly link in the debugger?

What implementation approach is libgdb taking? Does it expect the front
end to link directly to it, so that a front end is tied to a particular
version of GDB?

I like the idea of a libgdb that is capable of communicating with any
version of GDB that talks a valid MI protocol. This makes the library
more flexible. I guess this is essentially the goal I am working towards
with libtgdb.

Bob Rossi

Re: Bob's MI objective

[Fabian Cenedese]

>> >Understood, here is what I am hoping for at a minimum. 
>> >
>> >   * GDB supports at least 1 MI protocol for an official release. 
>> >     Supporting multiple MI protocols would be better for me, but 
>> >     not a requirement. If GDB could support multiple protocols it 
>> >     would improve the chances of a given front end working with a
>> >     given GDB.
>> 
>> But by "support" what do you mean - even a dictionary definition.  GDB 
>> includes at least one MI implementation, but that says nothing about how 
>> well it is either implemented or supported.
>
>That's a good question.
>
>Well, by support I simply mean, GDB is officially saying that a
>particular MI protocol is implemented as it should be, that it is tested
>to make sure that it works to the best of the GDB developers knowledge and 
>that it is safe to use by front ends.
>
>I am assuming that MI protocols in development ( right after a version
>bump, but before a major release ) is considered unsupported. By this I
>guess I mean that it should not be used by front ends until it is
>stable. Maybe a better word for "support" in this context is "stable".

I think the implementation grade is quite important. Though mi2 is
considered now the official and stable mi version I find that half of it
is unimplemented which makes it somehow useless for me. From
this point of view I'd say mi2 is the development version.
(And yes, I'm not only complaining, I have started implementing some
of the missing mi functions.)

Thanks

bye  Fabi

Re: Bob's MI objective

[Bob Rossi]

On Fri, Oct 08, 2004 at 08:56:19AM +0200, Fabian Cenedese wrote:
> 
> >> >Understood, here is what I am hoping for at a minimum. 
> >> >
> >> >   * GDB supports at least 1 MI protocol for an official release. 
> >> >     Supporting multiple MI protocols would be better for me, but 
> >> >     not a requirement. If GDB could support multiple protocols it 
> >> >     would improve the chances of a given front end working with a
> >> >     given GDB.
> >> 
> >> But by "support" what do you mean - even a dictionary definition.  GDB 
> >> includes at least one MI implementation, but that says nothing about how 
> >> well it is either implemented or supported.
> >
> >That's a good question.
> >
> >Well, by support I simply mean, GDB is officially saying that a
> >particular MI protocol is implemented as it should be, that it is tested
> >to make sure that it works to the best of the GDB developers knowledge and 
> >that it is safe to use by front ends.
> >
> >I am assuming that MI protocols in development ( right after a version
> >bump, but before a major release ) is considered unsupported. By this I
> >guess I mean that it should not be used by front ends until it is
> >stable. Maybe a better word for "support" in this context is "stable".
> 
> I think the implementation grade is quite important. Though mi2 is
> considered now the official and stable mi version I find that half of it
> is unimplemented which makes it somehow useless for me. From
> this point of view I'd say mi2 is the development version.
> (And yes, I'm not only complaining, I have started implementing some
> of the missing mi functions.)

Yes, I understand what you mean here, however, it is a slightly
different problem.

I am strictly calling an MI protocol a "development version of MI" if
the MI output syntax has not been nailed down ( I've got the hammer )
for an official release. I know there are other reasons why a version of
MI could be under development, I am just picking on this one case.

I've already described the problem were GDB is released with a stable MI
protocol. Then development begins for the next release. A backwards
incompatibility happens and the MI version is bumped and the MI output 
syntax changes. Before the next release another incompatible change can
occur and the MI output syntax could change again without a version
bump. For this reason, a front end could never communicate with all of
these MI protocols ( different grammars ), until a release has been made
and the protocol syntax is stable.

Even though I might be asking hypothetical questions, I was trying to
determine what things would cause the MI protocol to get bumped, so we
could figure out what constitutes a development version and what is a
stable version.

This is why I asked if adding new functions bumps the version, however,
several people suggested it shouldn't.

Thanks,
Bob Rossi

Re: Bob's MI objective

[Bob Rossi]

On Wed, Oct 06, 2004 at 05:26:52PM -0400, Bob Rossi wrote:
> On Wed, Oct 06, 2004 at 04:12:32PM -0400, Andrew Cagney wrote:
> > Bob, what's your overall objective here?  Perhaphs our lack of 
> > appreciation of your overriding goals is the reason that some (at least 
> > I) are feeling somewhat puzzled and confused.

Andrew, I would really like some closure on these issues, and since you
are the only MI maintainer that responds publically, I figured you could
help me out here.

I asked this question a week ago and still do not know the answer. This
is some information I must know in order to figure out how my front end
will deal with different versions of GDB, including CVS snapshots.

When I use "support" below, I mainly mean tested in the testsuite and
considered stable. 

>    * I would like to know what GDB's policy is in regards to supporting old
>      MI protocols.  ( I have received several opposing views on this )

A new way to phrase this would be, for a given release of GDB (not a CVS
snapshot), does that release support one MI protocol, or does it support
several MI protocols. The MI protocols need to be tested and stable.
A backwards incompatible change would bump the revision.

>    * I would like to ensure that my front end works well with snapshots
>      of GDB. I do not want to work with the MI development protocol, I
>      just want to work with the last officially supported protocol.

For CVS snapshots, does GDB only support (tested) the development MI
protocol? or does it support the last stable protocol? or does it
support multiple stable protocols?

A backwards incompatible change at this point would bump the revision at
first, but every other backwards compatible revision would not bump the
revision until the release, which then the protocol becomes tested and
stable.

>    * I would like to make sure that development protocols are never used
>      by my front end and that I can figure out all of the officially 
>      supported MI protocols that a given GDB supports.

This issue can have different solutions if we know the answer to the
questions above.

Thanks,
Bob Rossi

Re: Bob's MI objective

[Eli Zaretskii]

> Date: Thu, 7 Oct 2004 22:32:43 -0400
> From: Bob Rossi <bob@brasko.net>
> 
> >    * I would like to know what GDB's policy is in regards to supporting old
> >      MI protocols.  ( I have received several opposing views on this )
> 
> A new way to phrase this would be, for a given release of GDB (not a CVS
> snapshot), does that release support one MI protocol, or does it support
> several MI protocols. The MI protocols need to be tested and stable.

The answer to this is that, although the latest stable MI version is
probably the most stable version to rely upon, the old MI versions are
also supported to the degree that there are tests in the test suite
that exercise them.  For example, currently there are tests for mi1
although the latest MI version is mi2.

Of course, bugs in MI versions other than the latest will probably not
be corrected.

> >    * I would like to ensure that my front end works well with snapshots
> >      of GDB. I do not want to work with the MI development protocol, I
> >      just want to work with the last officially supported protocol.
> 
> For CVS snapshots, does GDB only support (tested) the development MI
> protocol? or does it support the last stable protocol? or does it
> support multiple stable protocols?

Again, the answer is that the support guarantee is the same for the
CVS versions: whatever the test suite exercises is supported to the
same degree.

Re: Bob's MI objective

[Bob Rossi]

On Fri, Oct 08, 2004 at 01:41:50PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 7 Oct 2004 22:32:43 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > >    * I would like to know what GDB's policy is in regards to supporting old
> > >      MI protocols.  ( I have received several opposing views on this )
> > 
> > A new way to phrase this would be, for a given release of GDB (not a CVS
> > snapshot), does that release support one MI protocol, or does it support
> > several MI protocols. The MI protocols need to be tested and stable.
> 
> The answer to this is that, although the latest stable MI version is
> probably the most stable version to rely upon, the old MI versions are
> also supported to the degree that there are tests in the test suite
> that exercise them.  For example, currently there are tests for mi1
> although the latest MI version is mi2.
> 
> Of course, bugs in MI versions other than the latest will probably not
> be corrected.

Right, I wouldn't expect them to be.

OK, Andrew gave me the exact opposite answer here. That is why I asked again
   http://sources.redhat.com/ml/gdb/2004-10/msg00177.html

maybe I'm wrong, and you guys are saying the same thing?

> > >    * I would like to ensure that my front end works well with snapshots
> > >      of GDB. I do not want to work with the MI development protocol, I
> > >      just want to work with the last officially supported protocol.
> > 
> > For CVS snapshots, does GDB only support (tested) the development MI
> > protocol? or does it support the last stable protocol? or does it
> > support multiple stable protocols?
> 
> Again, the answer is that the support guarantee is the same for the
> CVS versions: whatever the test suite exercises is supported to the
> same degree.

It is important to me that the CVS snapshots try to at least honor the
last major MI version before the version bump. Is this something
everyone thinks will be possible?

I do understand that old MI protocols could be dropped because of
maintenance issues. Would we go as far as dropping the last stable
protocol, this could potentially be a problem for me.

Thanks,
Bob Rossi

Re: Bob's MI objective

[Eli Zaretskii]

> Date: Fri, 8 Oct 2004 08:13:21 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: cagney@gnu.org, gdb@sources.redhat.com
> 
> OK, Andrew gave me the exact opposite answer here. That is why I asked again
>    http://sources.redhat.com/ml/gdb/2004-10/msg00177.html
> 
> maybe I'm wrong, and you guys are saying the same thing?

It surely sounds like Andrew is saying that all versions of MI except
the latest one are completely unsupported and broken, but I really
doubt he meant that.  After all, if that were the case, why would we
bother to keep those older versions in GDB?

But please wait for Andrew's definitive response.

> It is important to me that the CVS snapshots try to at least honor the
> last major MI version before the version bump. Is this something
> everyone thinks will be possible?

I think that an MI version that was just been superceded by a newer
one will not bitrot right away.  So you can count on it for quite some
time.  Also, all the tests for that version are still there to make
sure it works at least as well as it used to.

> I do understand that old MI protocols could be dropped because of
> maintenance issues. Would we go as far as dropping the last stable
> protocol, this could potentially be a problem for me.

I don't think the GDB maintainers will ever agree to such a radical
measure, even if someone were to suggest it.

Re: Bob's MI objective

[Daniel Jacobowitz]

On Fri, Oct 08, 2004 at 08:13:21AM -0400, Bob Rossi wrote:
> It is important to me that the CVS snapshots try to at least honor the
> last major MI version before the version bump. Is this something
> everyone thinks will be possible?

Try, yes.  Succeed, no, not always.  In an earlier message I described
various fixes to GDB's internals which would make honoring an MI
protocol that did not express them extremely difficult.

-- 
Daniel Jacobowitz

Re: Bob's MI objective

[Daniel Jacobowitz]

On Fri, Oct 08, 2004 at 01:41:50PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 7 Oct 2004 22:32:43 -0400
> > From: Bob Rossi <bob@brasko.net>
> > 
> > >    * I would like to know what GDB's policy is in regards to supporting old
> > >      MI protocols.  ( I have received several opposing views on this )
> > 
> > A new way to phrase this would be, for a given release of GDB (not a CVS
> > snapshot), does that release support one MI protocol, or does it support
> > several MI protocols. The MI protocols need to be tested and stable.
> 
> The answer to this is that, although the latest stable MI version is
> probably the most stable version to rely upon, the old MI versions are
> also supported to the degree that there are tests in the test suite
> that exercise them.  For example, currently there are tests for mi1
> although the latest MI version is mi2.

That's not true any more; there were, and they were removed.  My
understanding is that we have been keeping the last stable protocol in
addition to the current development protocol.  Of course, there is not
much in the way of sample size here!

-- 
Daniel Jacobowitz

Re: Bob's MI objective

[Eli Zaretskii]

> Date: Fri, 8 Oct 2004 09:42:19 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Bob Rossi <bob@brasko.net>, cagney@gnu.org, gdb@sources.redhat.com
> 
> That's not true any more; there were, and they were removed.

That sounds like a mistake to me.  A bunch of small files like that
cannot possibly do any harm.

Andrew, can we resurrect them, please?

Re: Bob's MI objective

[Andrew Cagney]

@samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
@value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, ,
The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0.  The
previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and
selected with @samp{--interpreter=mi1}, is deprecated.  Earlier
@sc{gdb/mi} interfaces are no longer supported.

Re: Bob's MI objective

[Bob Rossi]

On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote:
> @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
> @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, ,
> The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0.  The
> previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and
> selected with @samp{--interpreter=mi1}, is deprecated.  Earlier
> @sc{gdb/mi} interfaces are no longer supported.

This is basically what I need to know. I've asked several times and
would very much appreciate an answer from the people that are capable of
giving it. (The answer could be a simple yes or no)

   * Will GDB support at least one stable MI protocol for an official release?
   (This answer is obviously "yes", and does not have to be answered)
   * Will GDB support more than one stable MI protocols for an official release?
   * Will GDB support one stable MI protocol for a CVS snapshot?
   * Will GDB support more than one stable MI protocols for a CVS snapshot?

BTW, The word "will" means that even if GDB supports only 1 official protocol currently, 
what about in the future?

These questions are a prerequisite in determining how my front end will
be able to interface with GDB. They are also a prerequisite to solving the
MI handshaking problem.

Thanks,
Bob Rossi

Re: Bob's MI objective

[Bob Rossi]

On Fri, Oct 08, 2004 at 06:10:26PM -0400, Bob Rossi wrote:
> On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote:
> > @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
> > @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, ,
> > The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0.  The
> > previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and
> > selected with @samp{--interpreter=mi1}, is deprecated.  Earlier
> > @sc{gdb/mi} interfaces are no longer supported.
> 
> This is basically what I need to know. I've asked several times and
> would very much appreciate an answer from the people that are capable of
> giving it. (The answer could be a simple yes or no)
> 
>    * Will GDB support at least one stable MI protocol for an official release?
>    (This answer is obviously "yes", and does not have to be answered)
>    * Will GDB support more than one stable MI protocols for an official release?
>    * Will GDB support one stable MI protocol for a CVS snapshot?
>    * Will GDB support more than one stable MI protocols for a CVS snapshot?
> 
> BTW, The word "will" means that even if GDB supports only 1 official protocol currently, 
> what about in the future?
> 
> These questions are a prerequisite in determining how my front end will
> be able to interface with GDB. They are also a prerequisite to solving the
> MI handshaking problem.

Andrew, I know that you are a very busy person.

You have asked me several questions and I politely responded to you. I
would appreciate it if you could give me the same respect. Could you
please answer the questions I've asked you, not only from this Email but
from the rest of the ones in this thread?

From your lack of response to my questions (at least you respond), and the 
*complete* lack of response from the other MI maintainers, I would say that 
there is a problem with the maintenance of the MI section. The problem is 
simply that I can not get general and simple answers about the MI code. I feel
that this should be something accomplishable ... do you?

Thanks,
Bob Rossi

Re: Bob's MI objective

[Andrew Cagney]

C'mon Bob, it's the Canadian thanksgiving long weekend!  Strewth!

> On Fri, Oct 08, 2004 at 06:10:26PM -0400, Bob Rossi wrote:
> 
>>> On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote:
>>
>>>> > @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
>>>> > @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, ,
>>>> > The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0.  The
>>>> > previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 and
>>>> > selected with @samp{--interpreter=mi1}, is deprecated.  Earlier
>>>> > @sc{gdb/mi} interfaces are no longer supported.

... and it is lifted straight from the manual.  That you did read the 
manual right?

>>> This is basically what I need to know. I've asked several times and
>>> would very much appreciate an answer from the people that are capable of
>>> giving it. (The answer could be a simple yes or no)

>>>    * Will GDB support at least one stable MI protocol for an official release?
>>>    (This answer is obviously "yes", and does not have to be answered)
>>>    * Will GDB support more than one stable MI protocols for an official release?

In the past GDB tested both mi1 and mi2 so that that stage they were 
probably described as "supported".  Now that only mi2 is tested, nad mi1 
is deprecated, your call.

>>>    * Will GDB support one stable MI protocol for a CVS snapshot?

The above does, right?

>>>    * Will GDB support more than one stable MI protocols for a CVS snapshot?

Who knows,

I still don't see the point of all this, in particular, if you're going 
to implement a library, why it has to be kept separate to GDB?

And as others have pointed out, you're creating a problem when there 
isn't one.

Andrew

Re: Bob's MI objective

[Bob Rossi]

On Sun, Oct 10, 2004 at 10:56:49PM -0400, Andrew Cagney wrote:
> C'mon Bob, it's the Canadian thanksgiving long weekend!  Strewth!

hehe, thanks for answering my questions! I'm just excited about getting
things working, that's all.

> >On Fri, Oct 08, 2004 at 06:10:26PM -0400, Bob Rossi wrote:
> >
> >>>On Fri, Oct 08, 2004 at 05:35:22PM -0400, Andrew Cagney wrote:
> >>
> >>>>> @samp{--interpreter=mi} (or @samp{--interpreter=mi2}) causes
> >>>>> @value{GDBN} to use the @dfn{@sc{gdb/mi} interface} (@pxref{GDB/MI, ,
> >>>>> The @sc{gdb/mi} Interface}) included since @var{GDBN} version 6.0.  
> >>>>The
> >>>>> previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3 
> >>>>and
> >>>>> selected with @samp{--interpreter=mi1}, is deprecated.  Earlier
> >>>>> @sc{gdb/mi} interfaces are no longer supported.
> 
> ... and it is lifted straight from the manual.  That you did read the 
> manual right?

Yes, i did, thanks.

> >>>This is basically what I need to know. I've asked several times and
> >>>would very much appreciate an answer from the people that are capable of
> >>>giving it. (The answer could be a simple yes or no)
> 
> >>>   * Will GDB support at least one stable MI protocol for an official 
> >>>   release?
> >>>   (This answer is obviously "yes", and does not have to be answered)
> >>>   * Will GDB support more than one stable MI protocols for an official 
> >>>   release?
> 
> In the past GDB tested both mi1 and mi2 so that that stage they were 
> probably described as "supported".  Now that only mi2 is tested, nad mi1 
> is deprecated, your call.

Yes, and if MI3 were created, MI2 would probably stick around for a
while, or at least until the release, right?

> >>>   * Will GDB support one stable MI protocol for a CVS snapshot?
> 
> The above does, right?
> 
> >>>   * Will GDB support more than one stable MI protocols for a CVS 
> >>>   snapshot?
> 
> Who knows,
> 
> I still don't see the point of all this, in particular, if you're going 
> to implement a library, why it has to be kept separate to GDB?
> 
> And as others have pointed out, you're creating a problem when there 
> isn't one.

I feel like Kerry, and everyone keeps calling me a flip flopper :)

Listen, there is a reason I need to know. I am trying to solve the
problem of probing GDB from a front end to determine what
version/versions of MI a particular version of GDB supports.

If GDB is only going to support 1 stable MI protocol, then GDB can
simply output the protocol that it supports when it is started up. There
is no reason to "probe" it, it can just tell the front end what protocol
it speaks.

However, if it can use multiple MI versions, then a handshake algorithm
must take place. Basically, GDB starts up saying that it can speak
several different protocols, and then the front end picks one, and then
GDB uses that protocol.

The implementation is easier for the first case. However, I think the
second case is necessary.

Bob Rossi

Re: Bob's MI objective

[Michael Chastain]

Bob Rossi writes:
> However, if it can use multiple MI versions, then a handshake algorithm
> must take place. Basically, GDB starts up saying that it can speak
> several different protocols, and then the front end picks one, and then
> GDB uses that protocol.

I haven't followed this thread too closely, but this seems simple and
natural to me.

Michael