Re: obsoleting annotate level 2

Re: obsoleting annotate level 2

[Mike Mueller]

Jim Blandy wrote:

> The plan has been, for a very long time, to remove all 
> annotations.  I proposed keeping level one annotations.  Here was 
> my rationale:

> Level one annotations are implemented by code at two or three 
> points in GDB.  They're not a big deal to maintain.  And they're 
> what current releases of Emacs use.

> Level two annotations are implemented by (I think) around eighty
> different bits of code, scattered throughout GDB.

> Thus, while level one annotations are only a small maintenance 
> burden, level two annotations are.  Even if Emacs had been using 
> level two annotations for years, we would be trying to get rid of 
> them.

Jim,

Our only concern is that annotate 2 is the basis of our 
application.  Our request is that the removal of annotate 2 is done 
when MI is stable and is successfully used by at least one 
application.  Until MI has reached that point, our application will 
be forced to depend on annotate 2.

Note that we are not arguing to keep annotate 2 around forever.  Our 
hope is simply that annotate 2 will stay around until MI reaches a 
mature and stable state.

Thanks,
Mike

Re: obsoleting annotate level 2

[Jim Blandy]

Mike Mueller <mmueller@cs.uri.edu> writes:
> Jim Blandy wrote:
> 
> > The plan has been, for a very long time, to remove all 
> > annotations.  I proposed keeping level one annotations.  Here was 
> > my rationale:
> 
> > Level one annotations are implemented by code at two or three 
> > points in GDB.  They're not a big deal to maintain.  And they're 
> > what current releases of Emacs use.
> 
> > Level two annotations are implemented by (I think) around eighty
> > different bits of code, scattered throughout GDB.
> 
> > Thus, while level one annotations are only a small maintenance 
> > burden, level two annotations are.  Even if Emacs had been using 
> > level two annotations for years, we would be trying to get rid of 
> > them.
> 
> Jim,
> 
> Our only concern is that annotate 2 is the basis of our 
> application.  Our request is that the removal of annotate 2 is done 
> when MI is stable and is successfully used by at least one 
> application.  Until MI has reached that point, our application will 
> be forced to depend on annotate 2.

MI is already successfully in use by one (admittedly non-free)
application --- Apple's Power Builder.  Eclipse uses it now, too.

MI is, by design, always going to be more stable than annotation level
two.  MI imposes more structure on its output than annotation level
two does.

So I think MI is ready for the transition.

When you do find something you need, ask here.  In most cases, it's
very easy to add something to MI; when an easy case comes up, I'll
point it out, and you can get a chance to try doing it yourself.  Once
you can write your own patches to provide what you need, and you
understand the GDB coding standards, I think things will go very
quickly for you.

Re: obsoleting annotate level 2

[Bob Rossi]

On Wed, Feb 05, 2003 at 01:48:17AM -0500, Jim Blandy wrote:
> 
> Mike Mueller <mmueller@cs.uri.edu> writes:
> > Jim Blandy wrote:
> > 
> > > The plan has been, for a very long time, to remove all 
> > > annotations.  I proposed keeping level one annotations.  Here was 
> > > my rationale:
> > 
> > > Level one annotations are implemented by code at two or three 
> > > points in GDB.  They're not a big deal to maintain.  And they're 
> > > what current releases of Emacs use.
> > 
> > > Level two annotations are implemented by (I think) around eighty
> > > different bits of code, scattered throughout GDB.
> > 
> > > Thus, while level one annotations are only a small maintenance 
> > > burden, level two annotations are.  Even if Emacs had been using 
> > > level two annotations for years, we would be trying to get rid of 
> > > them.
> > 
> > Jim,
> > 
> > Our only concern is that annotate 2 is the basis of our 
> > application.  Our request is that the removal of annotate 2 is done 
> > when MI is stable and is successfully used by at least one 
> > application.  Until MI has reached that point, our application will 
> > be forced to depend on annotate 2.
> 
> MI is already successfully in use by one (admittedly non-free)
> application --- Apple's Power Builder.  Eclipse uses it now, too.
> 
> MI is, by design, always going to be more stable than annotation level
> two.  MI imposes more structure on its output than annotation level
> two does.
> 
> So I think MI is ready for the transition.
> 
> When you do find something you need, ask here.  In most cases, it's
> very easy to add something to MI; when an easy case comes up, I'll
> point it out, and you can get a chance to try doing it yourself.  Once
> you can write your own patches to provide what you need, and you
> understand the GDB coding standards, I think things will go very
> quickly for you.

Is gdb-mi ready to be used in gdb-5.3? or should I check out the cvs
tree in order to start building the new interface between cgdb and gdb?

Bobby

Re: obsoleting annotate level 2

[Andrew Cagney]

>  > Thus, while level one annotations are only a small maintenance burden,
>  > level two annotations are.  Even if Emacs had been using level two
>  > annotations for years, we would be trying to get rid of them.
> 
> A possible further reason for keeping level one annotations is that, like
> GDB/MI, it is really a machine interface (that is the output is intended to
> be read by a program). 
> 
> How about renaming it GDB/MI level 0 ;-)

Try `-1' :-)  mi level 0 was included in GDB 5.0.

Andrew

Re: obsoleting annotate level 2

[Nick Roberts]

 > Thus, while level one annotations are only a small maintenance burden,
 > level two annotations are.  Even if Emacs had been using level two
 > annotations for years, we would be trying to get rid of them.

A possible further reason for keeping level one annotations is that, like
GDB/MI, it is really a machine interface (that is the output is intended to
be read by a program). 

How about renaming it GDB/MI level 0 ;-)

Nick

Re: obsoleting annotate level 2

[Jim Blandy]

Elena Zannoni <ezannoni@redhat.com> writes:
> Bob Rossi writes:
>  > I understand that we will have to support both interfaces to gdb. That
>  > is not the issue at all. The issue is, annotate level 2 and 1 should not
>  > be removed from gdb because existing software relies on them.
>  > 
> 
> I just wanted to state that explicitly, nothing more.
> 
>  > That is why you are leaving annotate level 1, is that correct?
>  > 
> 
> I think annotate 1 is staying because Emacs uses it. However, as I
> understand it, there is the will from the Emacs community to start
> using MI, this is why Andrew is accelerating the merge of the
> interpreter code. Once MI is adopted by Emacs, I don't know what
> happens to annotation.

The plan has been, for a very long time, to remove all annotations.  I
proposed keeping level one annotations.  Here was my rationale:

Level one annotations are implemented by code at two or three points
in GDB.  They're not a big deal to maintain.  And they're what current
releases of Emacs use.

Level two annotations are implemented by (I think) around eighty
different bits of code, scattered throughout GDB.

Thus, while level one annotations are only a small maintenance burden,
level two annotations are.  Even if Emacs had been using level two
annotations for years, we would be trying to get rid of them.

Re: obsoleting annotate level 2

[Elena Zannoni]

Peter Kovacs writes:
 > On Tue, Feb 04, 2003 at 11:34:31AM -0500, Elena Zannoni wrote:
 > > If you have to keep supporting the old gdb, you will need to support
 > > two interfaces to gdb. Unless you are importing MI into
 > > 4.17.gnat.3.14p-1. If you have no control over 4.17.gnat.3.14p-1, and
 > > supporting that is your primary goal, I don't see what FSF gdb can do
 > > to correct that, ie I see two conflicting goals here.
 > 
 > Yes, we will continue to support --annotate=2 as well as the MI
 > interface.  I'm not sure why you see 2 conflicting goals.  Both
 > interfaces can be supported with no problems, after all we're not
 > interested in embedding our code into gdb itself.

OK, just wanted to point that out. They seem a conflicting in the
sense that one gdb is very old, and very different from the current
FSF one, but if you are ok with maintaining 2 interfaces, there is no
problem.

 > 
 > >  > As for the MI issues, I think we'd be willing to move over to the MI
 > >  > interface if and when it supports some of the readline style of input.
 > > 
 > > About readline, there was a conscious design decision to not provide
 > > it with MI, because the editing capabilities would be implemented at a
 > > different level, in the GUI console, not in gdb. With the interpreter
 > > changes the console becomes now a concrete possibility.  BTW, you may
 > > want to take a look at Apple's Project Builder, I don't know what
 > > level of editing they provided with their console.
 > 
 > I'm not sure I understand this.  How can the stand-alone GUI query gdb
 > for a list of symbol names?  For example, I type break m<tab>, and it
 > completes to "main".
 > 

there is a bug open against the lack of a 'completion' kind of
command in MI. See bug 953 in http://sources.redhat.com/gdb/bugs/

 > Unfortunately I don't have access to Apple's Project Builder.  Do they
 > offer the source to their debugger?
 > 

I think they do on their website. I don't have a pointer handy, sorry.

 > gdb's console is already quite capable, and many people are extremely
 > familiar with it.  I think it would be a shame if we have to completely
 > reimplement a console front-end to gdb.
 > 

insight does this too. Maybe that's another place to look.

elena


 > - Peter
 > 
 > -- 
 > Peter D. Kovacs <peter@kovax.org>

Re: obsoleting annotate level 2

[Elena Zannoni]

Bob Rossi writes:
 > I understand that we will have to support both interfaces to gdb. That
 > is not the issue at all. The issue is, annotate level 2 and 1 should not
 > be removed from gdb because existing software relies on them.
 > 

I just wanted to state that explicitly, nothing more.

 > That is why you are leaving annotate level 1, is that correct?
 > 

I think annotate 1 is staying because Emacs uses it. However, as I
understand it, there is the will from the Emacs community to start
using MI, this is why Andrew is accelerating the merge of the
interpreter code. Once MI is adopted by Emacs, I don't know what
happens to annotation.

elena

 > Thanks,
 > Bobby       
 > 
 > On Tue, Feb 04, 2003 at 11:34:31AM -0500, Elena Zannoni wrote:
 > > Peter Kovacs writes:
 > >  > On Tue, Feb 04, 2003 at 10:53:51AM -0500, Elena Zannoni wrote:
 > >  > > Interesting, I don't know if you are aware, gdb has already a curses
 > >  > > interface. configure gdb with --enable-tui and invoke with --tui.
 > >  > > 
 > >  > > Documentation is at:
 > >  > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197
 > >  > > 
 > >  > > Would it make sense to unify the efforts? Even though i see you want a 
 > >  > > completely separate UI.
 > >  > 
 > >  > I am also a developer on the cgdb project.  We discussed to some length
 > >  > the possibility of unifying the efforts and we decided it might not be
 > >  > such a good idea because:
 > >  > 
 > >  > 1. We need to use cgdb with older versions of gdb such as
 > >  >    4.17.gnat.3.14p-1, which we've standardized on here at work.
 > >  > 2. We wish to keep future compatibility with other console debuggers
 > >  >    (perl -d, jdb, etc).
 > >  > 
 > >  > Really point #1 is a deal-breaker for us.  It is basically the entire
 > >  > reason we started this project.  We do hope that cgdb can be written in
 > >  > such a way that it could become the default curses front-end to gdb, but
 > >  > we certainly don't want to step on any toes in that regard.
 > > 
 > > If you have to keep supporting the old gdb, you will need to support
 > > two interfaces to gdb. Unless you are importing MI into
 > > 4.17.gnat.3.14p-1. If you have no control over 4.17.gnat.3.14p-1, and
 > > supporting that is your primary goal, I don't see what FSF gdb can do
 > > to correct that, ie I see two conflicting goals here.
 > > 
 > >  > 
 > >  > As for the MI issues, I think we'd be willing to move over to the MI
 > >  > interface if and when it supports some of the readline style of input.
 > > 
 > > About readline, there was a conscious design decision to not provide
 > > it with MI, because the editing capabilities would be implemented at a
 > > different level, in the GUI console, not in gdb. With the interpreter
 > > changes the console becomes now a concrete possibility.  BTW, you may
 > > want to take a look at Apple's Project Builder, I don't know what
 > > level of editing they provided with their console.
 > > 
 > > elena
 > > 
 > > 
 > >  > Cgdb is designed to offer *everything* that gdb does plus some extras
 > >  > (source view, break points, shortcut commands).  I'm not entirely sure
 > >  > what work has been going on in this area, as I've just recently started
 > >  > paying attention to this list.  
 > >  > 
 > >  > Thanks,
 > >  > Peter Kovacs
 > >  > 
 > >  > -- 
 > >  > Peter D. Kovacs <peter@kovax.org>

Re: obsoleting annotate level 2

[Peter Kovacs]

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

> I'm not sure I understand this.  How can the stand-alone GUI query gdb
> for a list of symbol names?  For example, I type break m<tab>, and it
> completes to "main".

Sorry, I was just informed about the 'complete' capabilities of gdb.
However I still feel that my points regarding gdb's console still stand.

-- 
Peter D. Kovacs <peter@kovax.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: obsoleting annotate level 2

[Peter Kovacs]

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

On Tue, Feb 04, 2003 at 11:34:31AM -0500, Elena Zannoni wrote:
> If you have to keep supporting the old gdb, you will need to support
> two interfaces to gdb. Unless you are importing MI into
> 4.17.gnat.3.14p-1. If you have no control over 4.17.gnat.3.14p-1, and
> supporting that is your primary goal, I don't see what FSF gdb can do
> to correct that, ie I see two conflicting goals here.

Yes, we will continue to support --annotate=2 as well as the MI
interface.  I'm not sure why you see 2 conflicting goals.  Both
interfaces can be supported with no problems, after all we're not
interested in embedding our code into gdb itself.

>  > As for the MI issues, I think we'd be willing to move over to the MI
>  > interface if and when it supports some of the readline style of input.
> 
> About readline, there was a conscious design decision to not provide
> it with MI, because the editing capabilities would be implemented at a
> different level, in the GUI console, not in gdb. With the interpreter
> changes the console becomes now a concrete possibility.  BTW, you may
> want to take a look at Apple's Project Builder, I don't know what
> level of editing they provided with their console.

I'm not sure I understand this.  How can the stand-alone GUI query gdb
for a list of symbol names?  For example, I type break m<tab>, and it
completes to "main".

Unfortunately I don't have access to Apple's Project Builder.  Do they
offer the source to their debugger?

gdb's console is already quite capable, and many people are extremely
familiar with it.  I think it would be a shame if we have to completely
reimplement a console front-end to gdb.

- Peter

-- 
Peter D. Kovacs <peter@kovax.org>

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: obsoleting annotate level 2

[Bob Rossi]

I understand that we will have to support both interfaces to gdb. That
is not the issue at all. The issue is, annotate level 2 and 1 should not
be removed from gdb because existing software relies on them.

That is why you are leaving annotate level 1, is that correct?

Thanks,
Bobby       

On Tue, Feb 04, 2003 at 11:34:31AM -0500, Elena Zannoni wrote:
> Peter Kovacs writes:
>  > On Tue, Feb 04, 2003 at 10:53:51AM -0500, Elena Zannoni wrote:
>  > > Interesting, I don't know if you are aware, gdb has already a curses
>  > > interface. configure gdb with --enable-tui and invoke with --tui.
>  > > 
>  > > Documentation is at:
>  > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197
>  > > 
>  > > Would it make sense to unify the efforts? Even though i see you want a 
>  > > completely separate UI.
>  > 
>  > I am also a developer on the cgdb project.  We discussed to some length
>  > the possibility of unifying the efforts and we decided it might not be
>  > such a good idea because:
>  > 
>  > 1. We need to use cgdb with older versions of gdb such as
>  >    4.17.gnat.3.14p-1, which we've standardized on here at work.
>  > 2. We wish to keep future compatibility with other console debuggers
>  >    (perl -d, jdb, etc).
>  > 
>  > Really point #1 is a deal-breaker for us.  It is basically the entire
>  > reason we started this project.  We do hope that cgdb can be written in
>  > such a way that it could become the default curses front-end to gdb, but
>  > we certainly don't want to step on any toes in that regard.
> 
> If you have to keep supporting the old gdb, you will need to support
> two interfaces to gdb. Unless you are importing MI into
> 4.17.gnat.3.14p-1. If you have no control over 4.17.gnat.3.14p-1, and
> supporting that is your primary goal, I don't see what FSF gdb can do
> to correct that, ie I see two conflicting goals here.
> 
>  > 
>  > As for the MI issues, I think we'd be willing to move over to the MI
>  > interface if and when it supports some of the readline style of input.
> 
> About readline, there was a conscious design decision to not provide
> it with MI, because the editing capabilities would be implemented at a
> different level, in the GUI console, not in gdb. With the interpreter
> changes the console becomes now a concrete possibility.  BTW, you may
> want to take a look at Apple's Project Builder, I don't know what
> level of editing they provided with their console.
> 
> elena
> 
> 
>  > Cgdb is designed to offer *everything* that gdb does plus some extras
>  > (source view, break points, shortcut commands).  I'm not entirely sure
>  > what work has been going on in this area, as I've just recently started
>  > paying attention to this list.  
>  > 
>  > Thanks,
>  > Peter Kovacs
>  > 
>  > -- 
>  > Peter D. Kovacs <peter@kovax.org>

Re: obsoleting annotate level 2

[Elena Zannoni]

Peter Kovacs writes:
 > On Tue, Feb 04, 2003 at 10:53:51AM -0500, Elena Zannoni wrote:
 > > Interesting, I don't know if you are aware, gdb has already a curses
 > > interface. configure gdb with --enable-tui and invoke with --tui.
 > > 
 > > Documentation is at:
 > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197
 > > 
 > > Would it make sense to unify the efforts? Even though i see you want a 
 > > completely separate UI.
 > 
 > I am also a developer on the cgdb project.  We discussed to some length
 > the possibility of unifying the efforts and we decided it might not be
 > such a good idea because:
 > 
 > 1. We need to use cgdb with older versions of gdb such as
 >    4.17.gnat.3.14p-1, which we've standardized on here at work.
 > 2. We wish to keep future compatibility with other console debuggers
 >    (perl -d, jdb, etc).
 > 
 > Really point #1 is a deal-breaker for us.  It is basically the entire
 > reason we started this project.  We do hope that cgdb can be written in
 > such a way that it could become the default curses front-end to gdb, but
 > we certainly don't want to step on any toes in that regard.

If you have to keep supporting the old gdb, you will need to support
two interfaces to gdb. Unless you are importing MI into
4.17.gnat.3.14p-1. If you have no control over 4.17.gnat.3.14p-1, and
supporting that is your primary goal, I don't see what FSF gdb can do
to correct that, ie I see two conflicting goals here.

 > 
 > As for the MI issues, I think we'd be willing to move over to the MI
 > interface if and when it supports some of the readline style of input.

About readline, there was a conscious design decision to not provide
it with MI, because the editing capabilities would be implemented at a
different level, in the GUI console, not in gdb. With the interpreter
changes the console becomes now a concrete possibility.  BTW, you may
want to take a look at Apple's Project Builder, I don't know what
level of editing they provided with their console.

elena


 > Cgdb is designed to offer *everything* that gdb does plus some extras
 > (source view, break points, shortcut commands).  I'm not entirely sure
 > what work has been going on in this area, as I've just recently started
 > paying attention to this list.  
 > 
 > Thanks,
 > Peter Kovacs
 > 
 > -- 
 > Peter D. Kovacs <peter@kovax.org>

Re: obsoleting annotate level 2

[Peter Kovacs]

On Tue, Feb 04, 2003 at 10:53:51AM -0500, Elena Zannoni wrote:
> Interesting, I don't know if you are aware, gdb has already a curses
> interface. configure gdb with --enable-tui and invoke with --tui.
> 
> Documentation is at:
> http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197
> 
> Would it make sense to unify the efforts? Even though i see you want a 
> completely separate UI.

I am also a developer on the cgdb project.  We discussed to some length
the possibility of unifying the efforts and we decided it might not be
such a good idea because:

1. We need to use cgdb with older versions of gdb such as
   4.17.gnat.3.14p-1, which we've standardized on here at work.
2. We wish to keep future compatibility with other console debuggers
   (perl -d, jdb, etc).

Really point #1 is a deal-breaker for us.  It is basically the entire
reason we started this project.  We do hope that cgdb can be written in
such a way that it could become the default curses front-end to gdb, but
we certainly don't want to step on any toes in that regard.

As for the MI issues, I think we'd be willing to move over to the MI
interface if and when it supports some of the readline style of input.
Cgdb is designed to offer *everything* that gdb does plus some extras
(source view, break points, shortcut commands).  I'm not entirely sure
what work has been going on in this area, as I've just recently started
paying attention to this list.  

Thanks,
Peter Kovacs

-- 
Peter D. Kovacs <peter@kovax.org>

Re: obsoleting annotate level 2

[Elena Zannoni]

Bob Rossi writes:
 > Hi,
 > 
 > I have been writing a front end to gdb called cgdb. It depends on gdb's
 > annotate level 2 feature. This project can be downloaded at
 > cgdb.sourceforge.net. Before that it was hosted at tgdb.sourceforge.net.
 > 
 > It is a curses front end to gdb that is intended to be lightweight and
 > responsive. I originally wrote cgdb because I use gdb, sometimes for
 > several hours, during the day at work. We use GNAT's version of gdb
 > which seems to be behind GNU ( As far as version and features ).
 > 

Interesting, I don't know if you are aware, gdb has already a curses
interface. configure gdb with --enable-tui and invoke with --tui.

Documentation is at:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_22.html#SEC197

Would it make sense to unify the efforts? Even though i see you want a 
completely separate UI.

elena


 > I decided to make it a curses front end because there are many times
 > during the day when I ssh into a window's box using cygwin.
 > 
 > At the time I started developing cgdb ( about 8 month's ago ). I began
 > looking into how to interface with gdb without losing any of the
 > command line power. I began looking into how other debugger's did it.
 > So I soon realized that xxgdb, ddd and gvd all used annotate level 1.
 > I then did a little more research and discovered
 > http://www.gnu.org/manual/gdb/html_chapter/gdb_21.html#SEC203 which
 > encouraged me to use annotate level 2. Since even NOW, the manual says
 > nothing about annotate level 2 being deprecated, but describes how to
 > use the annotations.
 > 
 > I used annotate 2 to interface to gdb for several reasons:
 >    1. gdb-mi is not in older versions of gdb. Including GNAT's version
 >       of gdb ( which we use at work ). If I wrote a front end using this
 >       the gdb-mi feature of gdb, I would not be able to debug programs
 >       with GNAT, cygwin, red-hat, suse ... out of the box distributions.
 >       This seems UNACCEPTABLE.
 >    2. gdb-mi does not have readline support at the command line.
 >       This is an important feature if the GUI wants to keep gdb's
 >       useful command line feeling 100%.
 >    3. gdb-mi did not ( at the time ) support the CLI commands.
 >    4. annotate level 2 gave much more information to the GUI over
 >       annotate level 1. Including:
 >       1. When the user is interfacing with the readline library.
 >       2. When the breakpoints need to be checked (instead of every time).  
 >       3. The prompt can change. the debugged program can output the
 >       string '(gdb) ' to stdout without breaking the GUI.
 >       4. I was able to allow the user to communicate with the debugged
 >       program, no matter how the debugged program sets the terminal.
 >       ex. ( cbreak, raw ...)
 > 
 > I feel that cgdb should be separated from gdb for several reasons:
 >    1. cgdb should support a rich variety of options including
 >       1. macro support
 >       2. key bindings that do not have to be Emacs style
 >       3. configuration file for syntax color support ...
 >       4. regular expression searching
 >       5. many more options that can make cgdb easier to use.
 >    2. Users should not have to recompile gdb to get curses support.
 >    3. I can write cgdb knowing nothing about the internals of gdb,
 >       without sacrificing the risk of bugs in gdb for a GUI.
 > 
 > With these things in mind, I understand that gdb must move on. With or
 > without cgdb. Eventually cgdb will support gdb-mi. My only claim is that
 > gdb keep supporting annotate level 2 until it is ready to remove both
 > annotate level 1 and 2.
 > 
 > This way when other programs like gvd, ddd and xxgdb are rewritten to 
 > use gdb-mi and not annotate level 1, then programs like cgdb and
 > possibly others can be rewritten as well. I know these programs will use
 > gdb-mi when it is stable and ready. Util then, I don't think annotate
 > level 1 or 2 should be removed since there are existing front ends to gdb
 > that use them.
 > 
 > I believe this is fair. In fact, I am even willing to support annotate
 > level 2 if necessary. I know I have no association with GNU, but I would
 > be willing.
 > 
 > Thanks,
 > Bob Rossi

obsoleting annotate level 2

[Bob Rossi]

Hi,

I have been writing a front end to gdb called cgdb. It depends on gdb's
annotate level 2 feature. This project can be downloaded at
cgdb.sourceforge.net. Before that it was hosted at tgdb.sourceforge.net.

It is a curses front end to gdb that is intended to be lightweight and
responsive. I originally wrote cgdb because I use gdb, sometimes for
several hours, during the day at work. We use GNAT's version of gdb
which seems to be behind GNU ( As far as version and features ).

I decided to make it a curses front end because there are many times
during the day when I ssh into a window's box using cygwin.

At the time I started developing cgdb ( about 8 month's ago ). I began
looking into how to interface with gdb without losing any of the
command line power. I began looking into how other debugger's did it.
So I soon realized that xxgdb, ddd and gvd all used annotate level 1.
I then did a little more research and discovered
http://www.gnu.org/manual/gdb/html_chapter/gdb_21.html#SEC203 which
encouraged me to use annotate level 2. Since even NOW, the manual says
nothing about annotate level 2 being deprecated, but describes how to
use the annotations.

I used annotate 2 to interface to gdb for several reasons:
   1. gdb-mi is not in older versions of gdb. Including GNAT's version
      of gdb ( which we use at work ). If I wrote a front end using this
      the gdb-mi feature of gdb, I would not be able to debug programs
      with GNAT, cygwin, red-hat, suse ... out of the box distributions.
      This seems UNACCEPTABLE.
   2. gdb-mi does not have readline support at the command line.
      This is an important feature if the GUI wants to keep gdb's
      useful command line feeling 100%.
   3. gdb-mi did not ( at the time ) support the CLI commands.
   4. annotate level 2 gave much more information to the GUI over
      annotate level 1. Including:
      1. When the user is interfacing with the readline library.
      2. When the breakpoints need to be checked (instead of every time).  
      3. The prompt can change. the debugged program can output the
      string '(gdb) ' to stdout without breaking the GUI.
      4. I was able to allow the user to communicate with the debugged
      program, no matter how the debugged program sets the terminal.
      ex. ( cbreak, raw ...)

I feel that cgdb should be separated from gdb for several reasons:
   1. cgdb should support a rich variety of options including
      1. macro support
      2. key bindings that do not have to be Emacs style
      3. configuration file for syntax color support ...
      4. regular expression searching
      5. many more options that can make cgdb easier to use.
   2. Users should not have to recompile gdb to get curses support.
   3. I can write cgdb knowing nothing about the internals of gdb,
      without sacrificing the risk of bugs in gdb for a GUI.

With these things in mind, I understand that gdb must move on. With or
without cgdb. Eventually cgdb will support gdb-mi. My only claim is that
gdb keep supporting annotate level 2 until it is ready to remove both
annotate level 1 and 2.

This way when other programs like gvd, ddd and xxgdb are rewritten to 
use gdb-mi and not annotate level 1, then programs like cgdb and
possibly others can be rewritten as well. I know these programs will use
gdb-mi when it is stable and ready. Util then, I don't think annotate
level 1 or 2 should be removed since there are existing front ends to gdb
that use them.

I believe this is fair. In fact, I am even willing to support annotate
level 2 if necessary. I know I have no association with GNU, but I would
be willing.

Thanks,
Bob Rossi