[rfa:doco] Zap mi1 reference

[rfa:doco] Zap mi1 reference

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

Hello,

This removes a reference to "mi1" in the documentation.  It's no longer 
tested (hence 'supported').

Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 940 bytes --]

2004-02-13  Andrew Cagney  <cagney@redhat.com>

	* gdb.texinfo (Mode Options): Remove reference to "mi1".

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.193
diff -u -r1.193 gdb.texinfo
--- gdb.texinfo	6 Feb 2004 15:48:25 -0000	1.193
+++ gdb.texinfo	13 Feb 2004 20:03:00 -0000
@@ -1135,10 +1135,8 @@
 
 @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 in @var{GDBN} version 6.0.  The
-previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3,
-can be selected with @samp{--interpreter=mi1}.  Earlier @sc{gdb/mi}
-interfaces are not supported.
+The @sc{gdb/mi} Interface}) included in @var{GDBN} version 6.0.  Earlier
+@sc{gdb/mi} interfaces are not supported.
 
 @item -write
 @cindex @code{--write}

Re: [rfa:doco] Zap mi1 reference

[Bob Rossi]

On Fri, Feb 13, 2004 at 03:05:06PM -0500, Andrew Cagney wrote:
> Hello,
> 
> This removes a reference to "mi1" in the documentation.  It's no longer 
> tested (hence 'supported').

I don't really know how I feel about dropping support for old mi
versions. Is that the plan for future versions of mi?

I think the MI functions should be backwards compatible. Are they?

Bob Rossi

Re: [rfa:doco] Zap mi1 reference

[Eli Zaretskii]

> Date: Fri, 13 Feb 2004 15:05:06 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> This removes a reference to "mi1" in the documentation.  It's no longer
> tested (hence 'supported').

I don't think we should remove documentation of existing features,
even if they are not reliably supported.  How about adding some text
about mi1 being deprecated and unsupported instead?

Re: [rfa:doco] Zap mi1 reference

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

>> Date: Fri, 13 Feb 2004 15:05:06 -0500
>> From: Andrew Cagney <cagney@gnu.org>
>> 
>> This removes a reference to "mi1" in the documentation.  It's no longer
>> tested (hence 'supported').
> 
> 
> I don't think we should remove documentation of existing features,
> even if they are not reliably supported.  How about adding some text
> about mi1 being deprecated and unsupported instead?

Like this?

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1089 bytes --]

2004-02-13  Andrew Cagney  <cagney@redhat.com>

	* gdb.texinfo (Mode Options): Note that "mi1" is deprecated.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.193
diff -u -r1.193 gdb.texinfo
--- gdb.texinfo	6 Feb 2004 15:48:25 -0000	1.193
+++ gdb.texinfo	16 Feb 2004 22:25:17 -0000
@@ -1135,10 +1135,10 @@
 
 @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 in @var{GDBN} version 6.0.  The
-previous @sc{gdb/mi} interface, included in @value{GDBN} version 5.3,
-can be selected with @samp{--interpreter=mi1}.  Earlier @sc{gdb/mi}
-interfaces are not supported.
+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.
 
 @item -write
 @cindex @code{--write}

Re: [rfa:doco] Zap mi1 reference

[Andrew Cagney]

> On Fri, Feb 13, 2004 at 03:05:06PM -0500, Andrew Cagney wrote:
> 
>> Hello,
>> 
>> This removes a reference to "mi1" in the documentation.  It's no longer 
>> tested (hence 'supported').
> 
> 
> I don't really know how I feel about dropping support for old mi
> versions. Is that the plan for future versions of mi?

Well, neither can GDB support broken parts of the interface indefinitly :-(

The vague intent is to slowly phase in fixes while at the same time 
phasing out the testing and eventually the code for the old interfaces. 
  This should give a separate ui writer a year or so of grace with any 
specific MI version.

This goes with the assumption that separate UI authors are qualifying 
their interface against a specific GDB/MI version.

> I think the MI functions should be backwards compatible. Are they?

Theory or reality?  In theory the output is largely upward compatible - 
code can discard unrecognized fields.  In reality warts eventually start 
to appear.  For instance, both:
- using frame ID's with varobj
- N:M breakpoints
will impact significantly on the MI interface.

Andrew

Re: [rfa:doco] Zap mi1 reference

[Bob Rossi]

On Mon, Feb 16, 2004 at 06:27:14PM -0500, Andrew Cagney wrote:
> >On Fri, Feb 13, 2004 at 03:05:06PM -0500, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>This removes a reference to "mi1" in the documentation.  It's no longer 
> >>tested (hence 'supported').
> >
> >I think the MI functions should be backwards compatible. Are they?
> 
> Theory or reality?  In theory the output is largely upward compatible - 
> code can discard unrecognized fields.  In reality warts eventually start 
> to appear.  For instance, both:

In reality, I don't think front end writers will want to continually
depend on writing new MI interface layers in order to keep compatibility
with GDB.

As a front end writer, and as being interested in writing a thin layer
on top of MI, I am concerned with backwards compatibility.

I wrote an annotate-2 module that plugs into libtgdb. I wrote it using
gdb.5.3, however, it seems to work perfectly with versions of gdb as old
as 4.x. I am interested in seeing the same compatibility with MI.

If I was to write an MI module for libtgdb, do you see that working for
only gdb 6.0? Would I then have to write a MI2 module for 6.1? I would
hope that my MI1 library would work with both GDB 6.0,6.1. Is this a
quality the MI protocol is going to sustain? and that an MI2 module
would only allow for more functionality, or more of something.

> - using frame ID's with varobj
> - N:M breakpoints
> will impact significantly on the MI interface.

Will this break all MI1 front end clients?

Bob Rossi

Re: [rfa:doco] Zap mi1 reference

[Eli Zaretskii]

> Date: Mon, 16 Feb 2004 18:17:50 -0500
> From: Andrew Cagney <cagney@gnu.org>
> >
> > I don't think we should remove documentation of existing features,
> > even if they are not reliably supported.  How about adding some text
> > about mi1 being deprecated and unsupported instead?
> 
> Like this?

Yes, thanks.

Re: [rfa:doco] Zap mi1 reference

[Andrew Cagney]

> Date: Mon, 16 Feb 2004 18:17:50 -0500
>> From: Andrew Cagney <cagney@gnu.org>
> 
>> >
>> > I don't think we should remove documentation of existing features,
>> > even if they are not reliably supported.  How about adding some text
>> > about mi1 being deprecated and unsupported instead?
> 
>> 
>> Like this?
> 
> 
> Yes, thanks.

Tks, committed.

Andrew

Re: [rfa:doco] Zap mi1 reference

[Andrew Cagney]

> If I was to write an MI module for libtgdb, do you see that working for
> only gdb 6.0? Would I then have to write a MI2 module for 6.1? I would
> hope that my MI1 library would work with both GDB 6.0,6.1. Is this a
> quality the MI protocol is going to sustain? and that an MI2 module
> would only allow for more functionality, or more of something.
> 
> 
>> - using frame ID's with varobj
>> - N:M breakpoints
>> will impact significantly on the MI interface.
> 
> 
> Will this break all MI1 front end clients?

To turn the problem around, clients that don't exploit the new 
mechanisms are, by definition, already broken :-/

For instance without a frame ID it isn't possible for varobj to 
correctly identify a frame.  This means that when your existing code 
tries to debug frameless i386 backtraces it's going to fail in wierd and 
wonderful ways (typically by selecting the wrong frame).  Only by by 
identifying frames using a frame ID will your code be able to work robustly.

Andrew