[Various] obsoleting the annotate level 2 interface

[Various] obsoleting the annotate level 2 interface

[Jim Blandy]

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


Annotate 2 isn't dead after all!  Or, we took too long to delete it,
and it came back to life.  :(


[-- Attachment #2.1: Type: text/plain, Size: 267 bytes --]

Subject: Topics

Topics:
   obsoleting the annotate level 2 interface
   Re: obsoleting the annotate level 2 interface
   Re: obsoleting the annotate level 2 interface
   Re: obsoleting the annotate level 2 interface
   Re: obsoleting the annotate level 2 interface


[-- Attachment #2.2: Type: text/plain, Size: 3627 bytes --]

Date: Tue, 21 Jan 2003 19:02:21 +0000
From: Nick Roberts <nick@nick.uklinux.net>
To: Jim Blandy <jimb@redhat.com>
Cc: rms@gnu.org
Subject: obsoleting the annotate level 2 interface
Message-ID: <15917.39229.935851.920452@nick.uklinux.net>
References: <vt265sjj6vi.fsf@zenia.red-bean.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-length: 3257


There is a mode in the Emacs CVS repository (gdb-ui.el) that I have written
(based on gdba.el by Tom Lord and Jim Kingdon) that uses annotation level 2.
I did try to use GDB/MI when I started writing it but gave up because it
wasn't complete at the time (March/April last year). There was some discussion
on the mailing list and I felt that the folks working on the Eclipse project
became similarly disillusioned (I think that they might also currently use
annotation level 2). Additionally there was a debate about whether the command
line interface would be suported through GDB/MI as Richard Stallman was
anxious to keep the GUD buffer. Also, I think that DDD uses annotation level 1.

I had presumed that development on annotations had ceased and not that it
would be taken out. It has appeared quite robust to me and Andrew Cagney has
said as much. It would be a shame to lose it before GDB/MI has gained proven
acceptance.

Anyway, I'm sure that Richard will have something further to add.

Jim Blandy writes:
 > 
 > GDB seems to support two different ways of doing detailed annotations
 > of its output for consumption by other programs: MI and 'set annotate
 > 2'.  I don't think annotation level 2 has many active users, if any at
 > all.  It pervades GDB's code.  Would it make sense to put 'set
 > annotate 2' on the path to obsolescence?
 > 
 > Some background: the 'set annotate' command sets the
 > 'annotation_level' variable.  There are only three distinguished
 > values for this variable:
 > 
 > 0: nothing special, GDB behaves normally.
 > 1: in source.c:line_info and stack.c:print_frame_info, when we print
 >    the source line, we print out something extra that helps Emacs pop
 >    up the source code in a window.
 > 2 or greater: we enable around 250 calls to a variety of functions in
 >    annotate.c to mark and identify lots of things GDB prints.
 > 
 > I think we should keep level 1, since the standard Emacs GDB interface
 > uses it, and it's not very much code.
 > 
 > I'd like to see GDB dump level 2, since it duplicates MI, badly.  MI's
 > design ensures that whoever's trying to parse GDB's output gets
 > something that's well-formed, whereas annotate just sticks escape
 > codes into the outgoing stream of text.  This means that, if you
 > change the way anything prints, you may break an annotate level 2
 > client.  But to break an MI client, you actually have to change a
 > ui_out call, whose sole purpose is to produce output for clients to
 > read.  So MI is a much more maintainable approach, because it's easier
 > for people to see what they're doing.
 > 
 > If folks agree that annotate level 2 should go, we could:
 > - announce that annotate level 2 will be disabled in the release after
 >   next;
 > - in that release, disable the code, but leave it there, to see if
 >   anyone complains, and whether they can be persuaded to switch to MI;
 >   and
 > - in the release after that, if all goes well, remove the code to
 >   support annotation level 2.
 > 
 > Personally, I'd like to see Emacs switch from annotation level 1 to
 > MI, too; then we could get rid of annotation altogether.  But I think
 > it makes sense to tackle level 2 first, since I don't think it has
 > many users (if any).
 > 




[-- Attachment #2.3: Type: text/plain, Size: 4457 bytes --]

Date: Thu, 23 Jan 2003 03:00:15 -0500
From: Richard Stallman <rms@gnu.org>
to: hilfingr@CS.Berkeley.edu, vincent@waw.com, jimb@redhat.com,
   cagney@redhat.com, jtc@acorntoolworks.com, dewar@gnat.com, klee@apple.com,
   shebs@apple.com, toddpw@toddpw.org
cc: Nick Roberts <nick@nick.uklinux.net>
Subject: Re: obsoleting the annotate level 2 interface
Message-Id: <E18bcHX-0007cl-00@fencepost.gnu.org>
References: <vt265sjj6vi.fsf@zenia.red-bean.com> <15917.39229.935851.920452@nick.uklinux.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-length: 3879

Please don't drop the support for annotation level 2.
The new Emacs feature gdb-ui.el uses it.

If in the future people want to adapt Emacs to use MI instead, that
would be ok.  If Emacs is to use MI, it is essential to make the
command line work side by side with MI.


From: Nick Roberts <nick@nick.uklinux.net>
Date: Tue, 21 Jan 2003 19:02:21 +0000
To: Jim Blandy <jimb@redhat.com>
Cc: rms@gnu.org
Subject: obsoleting the annotate level 2 interface
In-Reply-To: <vt265sjj6vi.fsf@zenia.red-bean.com>
X-Spam-Status: No, hits=-5.4 required=5.0
	tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02
	version=2.41
X-Spam-Level: 


There is a mode in the Emacs CVS repository (gdb-ui.el) that I have written
(based on gdba.el by Tom Lord and Jim Kingdon) that uses annotation level 2.
I did try to use GDB/MI when I started writing it but gave up because it
wasn't complete at the time (March/April last year). There was some discussion
on the mailing list and I felt that the folks working on the Eclipse project
became similarly disillusioned (I think that they might also currently use
annotation level 2). Additionally there was a debate about whether the command
line interface would be suported through GDB/MI as Richard Stallman was
anxious to keep the GUD buffer. Also, I think that DDD uses annotation level 1.

I had presumed that development on annotations had ceased and not that it
would be taken out. It has appeared quite robust to me and Andrew Cagney has
said as much. It would be a shame to lose it before GDB/MI has gained proven
acceptance.

Anyway, I'm sure that Richard will have something further to add.

Jim Blandy writes:
 > 
 > GDB seems to support two different ways of doing detailed annotations
 > of its output for consumption by other programs: MI and 'set annotate
 > 2'.  I don't think annotation level 2 has many active users, if any at
 > all.  It pervades GDB's code.  Would it make sense to put 'set
 > annotate 2' on the path to obsolescence?
 > 
 > Some background: the 'set annotate' command sets the
 > 'annotation_level' variable.  There are only three distinguished
 > values for this variable:
 > 
 > 0: nothing special, GDB behaves normally.
 > 1: in source.c:line_info and stack.c:print_frame_info, when we print
 >    the source line, we print out something extra that helps Emacs pop
 >    up the source code in a window.
 > 2 or greater: we enable around 250 calls to a variety of functions in
 >    annotate.c to mark and identify lots of things GDB prints.
 > 
 > I think we should keep level 1, since the standard Emacs GDB interface
 > uses it, and it's not very much code.
 > 
 > I'd like to see GDB dump level 2, since it duplicates MI, badly.  MI's
 > design ensures that whoever's trying to parse GDB's output gets
 > something that's well-formed, whereas annotate just sticks escape
 > codes into the outgoing stream of text.  This means that, if you
 > change the way anything prints, you may break an annotate level 2
 > client.  But to break an MI client, you actually have to change a
 > ui_out call, whose sole purpose is to produce output for clients to
 > read.  So MI is a much more maintainable approach, because it's easier
 > for people to see what they're doing.
 > 
 > If folks agree that annotate level 2 should go, we could:
 > - announce that annotate level 2 will be disabled in the release after
 >   next;
 > - in that release, disable the code, but leave it there, to see if
 >   anyone complains, and whether they can be persuaded to switch to MI;
 >   and
 > - in the release after that, if all goes well, remove the code to
 >   support annotation level 2.
 > 
 > Personally, I'd like to see Emacs switch from annotation level 1 to
 > MI, too; then we could get rid of annotation altogether.  But I think
 > it makes sense to tackle level 2 first, since I don't think it has
 > many users (if any).
 > 






[-- Attachment #2.4: Type: text/plain, Size: 5549 bytes --]

Date: Thu, 23 Jan 2003 11:49:44 -0500
From: Andrew Cagney <ac131313@redhat.com>
To: rms@gnu.org
Cc: hilfingr@CS.Berkeley.edu, vincent@waw.com, jimb@redhat.com,
   cagney@redhat.com, jtc@acorntoolworks.com, dewar@gnat.com, klee@apple.com,
   shebs@apple.com, toddpw@toddpw.org, Nick Roberts <nick@nick.uklinux.net>
Subject: Re: obsoleting the annotate level 2 interface
Message-ID: <3E301D28.3060504@redhat.com>
References: <vt265sjj6vi.fsf@zenia.red-bean.com> <15917.39229.935851.920452@nick.uklinux.net> <E18bcHX-0007cl-00@fencepost.gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-length: 4923

> Please don't drop the support for annotation level 2.
> The new Emacs feature gdb-ui.el uses it.
> 
> If in the future people want to adapt Emacs to use MI instead, that
> would be ok.  If Emacs is to use MI, it is essential to make the
> command line work side by side with MI.

This is very very unfortunate.  The 5.1 release notes, from 2001-11-21 
clearly read:

> * The MI enabled by default.
> 
> The new machine oriented interface (MI) introduced in GDB 5.0 has been
> revised and enabled by default.  Packages which use GDB as a debugging
> engine behind a UI or another front end are encouraged to switch to
> using the GDB/MI interface, instead of the old annotations interface
> which is now deprecated.

GDB developers are working to resolve all known issues with MI that 
would block EMACS(1).  We really don't want to be in a situtation where 
we're forced to prop up the level two annotations.

For the record.  Eclipse is using MI and not annotations.  The 
frustrations the Eclipse group stemed largly from a lack of 
communication, on their part, with the GDB group.

Andrew



(1) Two are known.  The command line, and a tab-expand.


> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Tue, 21 Jan 2003 19:02:21 +0000
> To: Jim Blandy <jimb@redhat.com>
> Cc: rms@gnu.org
> Subject: obsoleting the annotate level 2 interface
> In-Reply-To: <vt265sjj6vi.fsf@zenia.red-bean.com>
> X-Spam-Status: No, hits=-5.4 required=5.0
> 	tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02
> 	version=2.41
> X-Spam-Level: 
> 
> 
> There is a mode in the Emacs CVS repository (gdb-ui.el) that I have written
> (based on gdba.el by Tom Lord and Jim Kingdon) that uses annotation level 2.
> I did try to use GDB/MI when I started writing it but gave up because it
> wasn't complete at the time (March/April last year). There was some discussion
> on the mailing list and I felt that the folks working on the Eclipse project
> became similarly disillusioned (I think that they might also currently use
> annotation level 2). Additionally there was a debate about whether the command
> line interface would be suported through GDB/MI as Richard Stallman was
> anxious to keep the GUD buffer. Also, I think that DDD uses annotation level 1.
> 
> I had presumed that development on annotations had ceased and not that it
> would be taken out. It has appeared quite robust to me and Andrew Cagney has
> said as much. It would be a shame to lose it before GDB/MI has gained proven
> acceptance.
> 
> Anyway, I'm sure that Richard will have something further to add.
> 
> Jim Blandy writes:
>  > 
>  > GDB seems to support two different ways of doing detailed annotations
>  > of its output for consumption by other programs: MI and 'set annotate
>  > 2'.  I don't think annotation level 2 has many active users, if any at
>  > all.  It pervades GDB's code.  Would it make sense to put 'set
>  > annotate 2' on the path to obsolescence?
>  > 
>  > Some background: the 'set annotate' command sets the
>  > 'annotation_level' variable.  There are only three distinguished
>  > values for this variable:
>  > 
>  > 0: nothing special, GDB behaves normally.
>  > 1: in source.c:line_info and stack.c:print_frame_info, when we print
>  >    the source line, we print out something extra that helps Emacs pop
>  >    up the source code in a window.
>  > 2 or greater: we enable around 250 calls to a variety of functions in
>  >    annotate.c to mark and identify lots of things GDB prints.
>  > 
>  > I think we should keep level 1, since the standard Emacs GDB interface
>  > uses it, and it's not very much code.
>  > 
>  > I'd like to see GDB dump level 2, since it duplicates MI, badly.  MI's
>  > design ensures that whoever's trying to parse GDB's output gets
>  > something that's well-formed, whereas annotate just sticks escape
>  > codes into the outgoing stream of text.  This means that, if you
>  > change the way anything prints, you may break an annotate level 2
>  > client.  But to break an MI client, you actually have to change a
>  > ui_out call, whose sole purpose is to produce output for clients to
>  > read.  So MI is a much more maintainable approach, because it's easier
>  > for people to see what they're doing.
>  > 
>  > If folks agree that annotate level 2 should go, we could:
>  > - announce that annotate level 2 will be disabled in the release after
>  >   next;
>  > - in that release, disable the code, but leave it there, to see if
>  >   anyone complains, and whether they can be persuaded to switch to MI;
>  >   and
>  > - in the release after that, if all goes well, remove the code to
>  >   support annotation level 2.
>  > 
>  > Personally, I'd like to see Emacs switch from annotation level 1 to
>  > MI, too; then we could get rid of annotation altogether.  But I think
>  > it makes sense to tackle level 2 first, since I don't think it has
>  > many users (if any).
>  > 
> 
> 
> 






[-- Attachment #2.5: Type: text/plain, Size: 1104 bytes --]

Date: Fri, 24 Jan 2003 12:16:12 -0500
From: Richard Stallman <rms@gnu.org>
To: Andrew Cagney <ac131313@redhat.com>
CC: hilfingr@CS.Berkeley.edu, vincent@waw.com, jimb@redhat.com,
   cagney@redhat.com, jtc@acorntoolworks.com, dewar@gnat.com, klee@apple.com,
   shebs@apple.com, toddpw@toddpw.org, nick@nick.uklinux.net, rms@gnu.org
Subject: Re: obsoleting the annotate level 2 interface
Message-Id: <E18c7R6-0007Ef-00@fencepost.gnu.org>
References: <vt265sjj6vi.fsf@zenia.red-bean.com> <15917.39229.935851.920452@nick.uklinux.net> <E18bcHX-0007cl-00@fencepost.gnu.org> <3E301D28.3060504@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-length: 424

    GDB developers are working to resolve all known issues with MI that 
    would block EMACS(1).  We really don't want to be in a situtation where 
    we're forced to prop up the level two annotations.

I support the goal of making Emacs use MI, but it may take some time
before this works, since it requires changes in GDB and bigger changes
in Emacs.  Please don't drop support for the annotations until this
works.




[-- Attachment #2.6: Type: text/plain, Size: 2212 bytes --]

Date: Mon, 27 Jan 2003 12:00:59 -0500
From: Andrew Cagney <ac131313@redhat.com>
To: rms@gnu.org
Cc: hilfingr@CS.Berkeley.edu, vincent@waw.com, jimb@redhat.com,
   cagney@redhat.com, jtc@acorntoolworks.com, dewar@gnat.com, klee@apple.com,
   shebs@apple.com, toddpw@toddpw.org, nick@nick.uklinux.net
Subject: Re: obsoleting the annotate level 2 interface
Message-ID: <3E3565CB.1040706@redhat.com>
References: <vt265sjj6vi.fsf@zenia.red-bean.com> <15917.39229.935851.920452@nick.uklinux.net> <E18bcHX-0007cl-00@fencepost.gnu.org> <3E301D28.3060504@redhat.com> <E18c7R6-0007Ef-00@fencepost.gnu.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-length: 1533

>     GDB developers are working to resolve all known issues with MI that 
>     would block EMACS(1).  We really don't want to be in a situtation where 
>     we're forced to prop up the level two annotations.
> 
> I support the goal of making Emacs use MI, but it may take some time
> before this works, since it requires changes in GDB and bigger changes
> in Emacs.  Please don't drop support for the annotations until this
> works.

My understanding is:

- To the best of my knowledge, all previous versions of EMACS use GDB's 
level-one annotations.

- This new (unreleased?) EMACS debug mode is different.  It is using 
level-two annotations even though GDB has deprecated support for this.

- JimB's proposal was to continue providing level-one annotations (and 
hence allow existing EMACS releases to work) but obsolete (and 
eventually remove) level-two annotations.

Supporting level-two annotations will involve an ongoing commitment of 
GDB developer resources (something we're sadly lacking).  I think those 
developer resources would be far better spent improving GDB's support of 
features such as Java, C++ and threads, and the far more powerful / 
robust / tested MI interface.

Consequently, I don't think it is reasonable to have GDB commit to 
supporting level-two annotations (something GDB has already deprecated) 
until the new EMACS mode is working with MI.  I believe that GDB should 
obsolete (and schedule the removal of) level-two annotations the moment 
the remaining MI work is completed.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

To summarize:

- gdb should implement the console
- gdb should implement the expand command jimI pointed out
- gdb can then make annotations obsolete (but not actually remove them 
for an extra release)

We may also want to print out the fact that level two annotations are 
deprecated.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Arnaud Charlet]

As one of the GVD (see http://libre.act-europe.fr/gvd) developers, I
confirm that to use the GDB/MI, we are waiting for a stabilized interface
(amny things have changed til recently in MI), and the ability to
support the command line interface for providing a regular gdb console.

Without these two critical points addressed by MI, there is no way we can
replace annotate 1 by MI.

Arno

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

> As one of the GVD (see http://libre.act-europe.fr/gvd) developers, I
> confirm that to use the GDB/MI, we are waiting for a stabilized interface
> (amny things have changed til recently in MI), and the ability to
> support the command line interface for providing a regular gdb console.
> 
> Without these two critical points addressed by MI, there is no way we can
> replace annotate 1 by MI.

The proposal is to drop level-two annotation but retain level one 
indefinitly.  It is level-two that causes all the grief in the code.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Eli Zaretskii]

On Tue, 28 Jan 2003, Andrew Cagney wrote:

> We may also want to print out the fact that level two annotations are 
> deprecated.

IMHO, it definitely needs to be stated in a very visible place that 
level-2 annotations are deprecated.  But I think it's more important to 
work on what's missing in MI, because it should be clear that as it 
currently stands, MI is not a complete solution to a GDB front end.

I actually tried very hard to convince the gdb-ui developer to use MI 
from day one, but given the lack of support for CLI commands, and the 
fact that no one of the GDB developers stepped forward to add the missing 
features when gdb-ui was still in limbo, I had no alternative but to 
agree that for now, level-2 annotations are the only practical way to go.

Re: [Various] obsoleting the annotate level 2 interface

[Arnaud Charlet]

> The proposal is to drop level-two annotation but retain level one 
> indefinitly.  It is level-two that causes all the grief in the code.

Thanks for clarifying. Since there were definitely different messages saying
different things on this subject, I'm glad this is clarified, and good
to hear that annotate 1 is not going to disappear.

Arno

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

> The proposal is to drop level-two annotation but retain level one 
>> indefinitly.  It is level-two that causes all the grief in the code.
> 
> 
> Thanks for clarifying. Since there were definitely different messages saying
> different things on this subject, I'm glad this is clarified, and good
> to hear that annotate 1 is not going to disappear.

Just to clarify this.

The entire annotation interface is deprecated -> no new project should 
use it.  Instead they should use MI and help improve that interface 
where necessary.

While projects might find that the level-one annotations work, they need 
to remember that the mechanism they are relying on is deprecated and, 
consequently, is receiving little of any attention.

I don't know about you, but if my project was in this situtation I'd be 
doing everything possible to move away from annotations and towards MI.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Arnaud Charlet]

> I don't know about you, but if my project was in this situtation I'd be 
> doing everything possible to move away from annotations and towards MI.

We're not going to drop annotations anytime soon, since supporting older
versions of gdb is important.

So in any case, we're talking about supporting *both* annotations and MI.

Since as I stated in a previous message, MI has currently known limitations and
drawbacks, I'm sure you'll agree that if you were in our situation, you
would hesitate adding support for MI at this stage, and would rather wait
for things to stabilize.

Once MI has stabilized and provides a way to have a command  line for end
users, then it will indeed be reasonable to concentrate on MI only.

Arno

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

>> I don't know about you, but if my project was in this situtation I'd be 
>> doing everything possible to move away from annotations and towards MI.
> 
> 
> We're not going to drop annotations anytime soon, since supporting older
> versions of gdb is important.
> 
> So in any case, we're talking about supporting *both* annotations and MI.
> 
> Since as I stated in a previous message, MI has currently known limitations and
> drawbacks, I'm sure you'll agree that if you were in our situation, you
> would hesitate adding support for MI at this stage, and would rather wait
> for things to stabilize.

Honestly?  No.  MI has `kick ass' features sufficent to justify the move 
now:

the varobj - which makes it possible for the IDE to provide good 
interactive performance
a real syntax - which frees the ide from CLI stupidity such as ``(gdb) 
set x = expression''.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Arnaud Charlet]

> Honestly?  No.  MI has `kick ass' features sufficent to justify the move 
> now:

Well fine, so we are in disagreement. Maybe the gdb GUI you've written does
not have the same requirements than GVD has.

I'm not saying MI does not have some added value compared to CLI, I'm just
saying (and I'm not the only one) that there are some missing features in MI
which are important enough to be taken into account.

Arno

Re: [Various] obsoleting the annotate level 2 interface

[Christopher Faylor]

On Wed, Jan 29, 2003 at 04:51:06PM +0100, Arnaud Charlet wrote:
>>Honestly?  No.  MI has `kick ass' features sufficent to justify the
>>move now:
>
>Well fine, so we are in disagreement.  Maybe the gdb GUI you've written
>does not have the same requirements than GVD has.
>
>I'm not saying MI does not have some added value compared to CLI, I'm
>just saying (and I'm not the only one) that there are some missing
>features in MI which are important enough to be taken into account.

And the missing features are...?

Re: [Various] obsoleting the annotate level 2 interface

[Arnaud Charlet]

> And the missing features are...?

I've stated them at least 3 times in this thread (which I assume is archived),
but here there are again:

- stability in the MI interface
- ability to provide a user console with the CLI syntax

Note that we haven't started implemented support for MI in GVD, so these are
really the two obvious features. Others may appear when we start implementing
the real support.

What are the gdb front-ends currently using MI ? It would be interesting to
see the state of these front-ends and the problems encountered.

Arno

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

>> And the missing features are...?
> 
> 
> I've stated them at least 3 times in this thread (which I assume is archived),
> but here there are again:
> 
> - stability in the MI interface

Um, by stable you mean?  Each iteration of GDB leads to changes in both 
the MI and the CLI.  However, at at least with the MI those changes are 
identified, documented and tested.

> - ability to provide a user console with the CLI syntax

People have been working on that.  Apple has a hacked GDB where it works 
NOW!

> Note that we haven't started implemented support for MI in GVD, so these are
> really the two obvious features. Others may appear when we start implementing
> the real support.
> 
> What are the gdb front-ends currently using MI ? It would be interesting to
> see the state of these front-ends and the problems encountered.

Apple's Project Builder.
The Eclipse project.

The problems they have encountered have been turned into bug reports. 
See the bug database.  The only big one is the console and both Apple 
and Eclipse managed to hack around it.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Arnaud Charlet]

> Um, by stable you mean?  Each iteration of GDB leads to changes in both 
> the MI and the CLI.  However, at at least with the MI those changes are 
> identified, documented and tested.

By stable I mean that the set of commands and their output are reasonably
stable and do not change significantly from one version to another.

> People have been working on that.  Apple has a hacked GDB where it works 
> NOW!

Right, that's not acceptable in the context of a multipurpose and portable
GUI front-end, where basically people can plug the version of gdb they like.
So Apple's approach of hacking a particular version of gdb is not feasible,
and not something that can be maintained in the long run.

> The problems they have encountered have been turned into bug reports. 
> See the bug database.  The only big one is the console and both Apple 
> and Eclipse managed to hack around it.

Does it mean that there are no plans to actually fix this critical missing
feature, and that each front-end will have to "hack around it" ?

I will look again at Eclipse support for gdb. Last time I looked, its
support was relatively simple, certainly not at the same level than what
GVD offers.

Arno

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

> Right, that's not acceptable in the context of a multipurpose and portable
> GUI front-end, where basically people can plug the version of gdb they like.
> So Apple's approach of hacking a particular version of gdb is not feasible,
> and not something that can be maintained in the long run.

Er, reality check.  Even ACT have a customized GDB.  I'm pretty sure 
that ACT, when shipping their GUI, only test it against one, and 
possibly two, local GDB releases.  Reality is that any GUI dependant on 
the CLI / annotations has reliability problems by design.

Apple, like everyone else, want to kill off their branch.

>> The problems they have encountered have been turned into bug reports. 
>> See the bug database.  The only big one is the console and both Apple 
>> and Eclipse managed to hack around it.
> 
> 
> Does it mean that there are no plans to actually fix this critical missing
> feature, and that each front-end will have to "hack around it" ?

I'd conclude the exact oposite.

Given the `big iron' supporting MI, it is very likely that dedicated 
resources can be found that fix these problems.  All the parties 
involved know that they can't sustain local GDB branches.

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Eli Zaretskii]

> Date: Wed, 29 Jan 2003 10:19:14 -0500
> From: Andrew Cagney <ac131313@redhat.com>
> 
> I don't know about you, but if my project was in this situtation I'd be 
> doing everything possible to move away from annotations and towards MI.

I agree with that, but if the front-end programmer cannot become a GDB
hacker, this approach might be impractical when he/she bumps into a
few problems in the current MI code.  That's what happened with the
gdb-gui.el programmer for Emacs.

So I think that if we want the front-ends to switch to MI ASAP,
someone on the GDB maintenance team should work with front-end
programmers on resolving the issues they raise.  We need to be
responsive to any bugs they report for them to get the feeling that
MI's support solves their problems.

Re: [Various] obsoleting the annotate level 2 interface

[Tom Tromey]

>>>>> "Arnaud" == Arnaud Charlet <charlet@ACT-Europe.FR> writes:

>> People have been working on that.  Apple has a hacked GDB where it works 
>> NOW!

Arnaud> Right, that's not acceptable in the context of a multipurpose
Arnaud> and portable GUI front-end, where basically people can plug
Arnaud> the version of gdb they like.  So Apple's approach of hacking
Arnaud> a particular version of gdb is not feasible, and not something
Arnaud> that can be maintained in the long run.

The Eclipse CDT developers decided to support only certain gdb
releases for a given CDT release.  Surely that is what everyone does
-- though Eclipse may support a much narrower range of gdb versions
than you would like.

Also, Eclipse currently doesn't have a console (to my knowledge; I
haven't played with the latest snapshots yet).  So some of the major
problems with MI are avoided.

Arnaud> Does it mean that there are no plans to actually fix this
Arnaud> critical missing feature, and that each front-end will have to
Arnaud> "hack around it" ?

My impression is that people are working on MI and trying to eliminate
the remaining problems.

Tom

Re: [Various] obsoleting the annotate level 2 interface

[Jim Blandy]

Ulrich Drepper <drepper@redhat.com> writes:
> On Tue, 28 Jan 2003, Andrew Cagney wrote:
> 
> > We may also want to print out the fact that level two annotations are 
> > deprecated.
> 
> IMHO, it definitely needs to be stated in a very visible place that 
> level-2 annotations are deprecated.  But I think it's more important to 
> work on what's missing in MI, because it should be clear that as it 
> currently stands, MI is not a complete solution to a GDB front end.

It was in NEWS.  We could add a warning to the "set annotation"
command, I guess.

Re: [Various] obsoleting the annotate level 2 interface

[Jim Blandy]

I think we can expect MI to continue to change over time.  It's a new
interface, and we're all still learning what we need from it, and how
it should behave.  To expect complete stability at this point is to
ensure that less-than-helpful behaviors also remain "stable".

While GDB developers should obviously take care when making MI-visible
changes (and I think they do), MI's clients also need to be tolerant
of the changes that will occur, and they need to be constructive ---
for example, by contributing test cases and good bug reports.

Re: [Various] obsoleting the annotate level 2 interface

[Nick Roberts]

Elena Zannoni writes:

 > Sorry, I am a bit behind in the history, didn't emacs always have an
 > interface to gdb?

This is my understanding of events. I've gleaned the information from the
internet and I'm using my memory so it may not be entirely accurate.

In the beginning, there was gud.el, started in 1992 by Eric Raymond. This used
`gdb -fullname', now rather grandly called, annotations level 1. It just puts
out one annotation, though, saying where it is each time execution stops. Then
annotations level 2 came along, which had many more annotations. Tom Lord and
Jim Kingdon  wrote gdba.el (1994?) `to demonstrate how to build a windowed GUI
over GDB using an Emacs-style framework' (Tom's words). This was a derivative
of gud.el and, in my opinion, a significant improvement. For some reason it
didn't make its way into the Emacs community. I don't know if many GDB users
became aware of it because it was only distributed with the source code for
GDB (?).

I first came across the code in gud.el in XEmacs. It appears that someone
attempted to (unsucessfully) port it there. XEmacs actually uses `M-x gdb' as
defined in another file (gdb.el). Eli Zaretskii told me that this code came
from gdba.el and I was surprised to find that it had been deleted from the GDB
distribution.  Eli explained that this was because annotations were now
deprecated. He also urged me to use GDB/MI and is now being proved right. It
didn't seem complete, at the time, and couldn't provide the command line
interface, so I clung to annotations as I felt I could make that work.
 
Anyway we have to move forward now and, hopefully, I've learnt a lot in the
process that will help with an MI implentation.

 > I am now curious, where can i get a copy of gdb-ui.el?

Its in the Emacs repository (http://savannah.gnu.org/projects/emacs). It uses
some recently defined lisp functions so it really needs to be run on an emacs
built from there.

Take a look at http://www.nick.uklinux.net/newscreenshot.png for an early
screenshot.

The commentary says:

;; This mode acts as a graphical user interface to GDB. You can interact with
;; GDB through the GUD buffer in the usual way, but there are also further
;; buffers which control the execution and describe the state of your program.
;; It separates the input/output of your program from that of GDB and displays
;; expressions and their current values in their own buffers. It also uses
;; features of Emacs 21 such as the display margin for breakpoints, and the
;; toolbar.

I think it works better with gdb than gud.el but, although it may be
grand, there is nothing unified about it i.e it doesn't work with dbx, pdb
etc (GUD stands for Grand Unified Debugger). The toolbar might look familiar as
most of the icons come from Insight.

 >          ... make sure you do things as publically as you can,
 > otherwise you may be stuck out on a limb, if the design is not
 > accepted by the community. It also would help in case somebody else
 > wants to become involved and help you. I have had my share of problems
 > in the past, for not doing things publically in the first place, I
 > ended up having to redo work, in a few occasions.

This sounds like good advice.

Nick

Re: [Various] obsoleting the annotate level 2 interface

[Jim Blandy]

Elena Zannoni <ezannoni@redhat.com> writes:
> I don't understand. The on line doc is up to date, it is not
> lying. Those commands have not been implememted. We have gone through
> 3 projects (one internal to Cygnus, eclipse, and the apple ui) and
> none of those missing commands was obviously a show stopper. Of course
> those are *new* GUIs and they can be less functional. Emacs cannot go
> backwards because some commands are missing. Does emacs need these
> commands? for instance, does emacs have a window that shows the
> threads of the inferior?

Well, we should be clear, here: the most recent Emacs release uses
only annotation level 1.  It's only a not-yet-released Emacs that has
a just-added mode that uses annotation level 2.  So if GDB were to
delete annotate level 2 today, Emacs would not lose any functionality.
(I am not suggesting that we delete annotation level 2 today, it's
just a rhetorical device.)

Re: [Various] obsoleting the annotate level 2 interface

[Jim Ingham]

Nick,

I don't think you need to be so worried.  We have been able to get 
pretty far without these.  Most of them are actually not very helpful.

See comments below...

On Friday, January 31, 2003, at 02:00  PM, 
gdb-digest-help@sources.redhat.com wrote:

> From: Nick Roberts <nick@nick.uklinux.net>
> Date: Fri Jan 31, 2003  12:11:07  PM US/Pacific
> To: gdb@sources.redhat.com
> Subject: Re: [Various] obsoleting the annotate level 2 interface
>
>
>> On Wed, 29 Jan 2003 10:56:02 -0500, Christopher Faylor wrote:
>>> On Wed, Jan 29, 2003 at 04:51:06PM +0100, Arnaud Charlet wrote:
>>>> Honestly?  No.  MI has `kick ass' features sufficent to justify the
>>>> move now:
>
>>> Well fine, so we are in disagreement.  Maybe the gdb GUI you've 
>>> written
>>> does not have the same requirements than GVD has.
>
>>> I'm not saying MI does not have some added value compared to CLI, I'm
>>> just saying (and I'm not the only one) that there are some missing
>>> features in MI which are important enough to be taken into account.
>
>> And the missing features are...?
>
> Well, the current online documentation at,
> http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC217,
> says (summarised) :
>
> Also note that the commands with a non-available example (N.A.) are 
> not yet
> implemented.
>
> -display-delete                 N.A.
> -display-disable                N.A.
> -display-enable                 N.A.
> -display-insert                 N.A.
> -display-list                   N.A.

A programmatic interface to gdb would just query the things it is 
interested in when it gets the stop message.  If you want these 
displayed in the console, the user can use the command-line display 
command.  So I am not even sure why these are here, probably an 
overzealous sense of completeness?

> -exec-abort                     N.A.

When things go bad, we always end up having to kill gdb, otherwise, the 
user usually kills the inferior themselves, or restarts it, which 
achieves this anyway.  So we haven't needed this.

> -exec-show-arguments            N.A.

PB - at least - always provides the arguments to gdb, so I am not sure 
why this are needed.

> -file-list-exec-sections        N.A.
> -file-list-exec-source-files    N.A.
> -file-list-shared-libraries     N.A.
> -file-list-symbol-files         N.A.

We did need a shared library info command, though we actually cooked up 
one of our own because we have to play lots of games to limit the 
amount of grubbing around in shared libraries that gdb does (an average 
MacOS X program has 40 or 50 dependent libraries, and many of them - 
especially the ObjC ones - have lots of external symbols...)  So we 
needed some slightly gnarlier commands.  But I doubt the emacs mode has 
a special-purpose shared library info pane, so listing these in the 
console is probably good enough.

> -stack-info-frame               N.A.
> -symbol-info-address            N.A.
> -symbol-info-file               N.A.
> -symbol-info-function           N.A.
> -symbol-info-line               N.A.
> -symbol-info-symbol             N.A.
> -symbol-list-functions          N.A.
> -symbol-list-types              N.A.
> -symbol-list-variables          N.A.
> -symbol-locate                  N.A.
> -symbol-type                    N.A.

A lot of these are unnecessary if you are using the varobj system.  We 
do stack displays, locals, and expressions window without them.  We 
haven't done a "view memory at the location of this symbol" but even 
then we wouldn't need -symbol-info-address, since we already have the 
varobj for the symbol, which has its address...

> -target-attach                  N.A.
> -target-compare-sections        N.A.
> -target-exec-status             N.A.
> -target-list-available-targets  N.A.
> -target-list-current-targets    N.A.
> -target-list-parameters         N.A.

Can't comment on these, we only do native debugging.

> -thread-info                    N.A.
> -thread-list-all-threads        N.A.

You can do everything you need for threads with the thread-list-ids and 
thread-select.  If you had a thread package that supported some native 
thread info like named threads or whatever then -thread-info would be 
useful.  Mac OS X doesn't do this, dunno if Linux does...  But this is 
definitely a second order thing.

We really have been able to get pretty far with the MI as it stands 
(plus the stuff that Andrew has so kindly offered to finish merging 
in.)  It is much more pleasant than trying to parse gdb output, which 
is what the old PB used to do.

Jim
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: [Various] obsoleting the annotate level 2 interface

[Nick Roberts]

 >  > Ah, don't be fooled by the current online documentation... ;-)

 > I don't understand. The on line doc is up to date, it is not
 > lying. 

Sorry, it was just a cheeky paraphrase of something Andrew Cagney said earlier.
Trying to be more helpful, the documentation says that -break-info has not
been implemented yet but it seems to work even on my version of gdb
(GNU gdb 20010813 (MI_OUT)). If -break-info does work, then presumably
-break-list is not needed.

 > Those commands have not been implememted. We have gone through
 > 3 projects (one internal to Cygnus, eclipse, and the apple ui) and
 > none of those missing commands was obviously a show stopper. 

gdb-ui.el currently uses the CLI equivalent of:

-display-delete 
-display-disable
-display-enable 
-display-insert 
-display-list   

although enable/disable probably aren't necessary. How do the other projects
display variables ?

 > Of course those are *new* GUIs and they can be less functional. Emacs
 > cannot go backwards because some commands are missing.

I imagine most modern GUIs are currently more functional than the one that I
have provided for Emacs. It is the context of Emacs where I think the value
of gdb-ui.el lies.

 > for instance, does emacs have a window that shows the threads of the
 > inferior?

I've done nothing about threads, partly because different operating systems
seem to treat them differently and partly from my lack of understanding of
them.

 > But it is not hard to implement them. These are fairly simple, almost
 > wrappers.

I agree there's no point of implementing them for the sake of it. If the
existing commands work for the three projects you mention, then they should
also work for Emacs. 

That just leaves the question of the console, which Andrew covers in his
e-mail.

Nick

Re: [Various] obsoleting the annotate level 2 interface

[Andrew Cagney]

> As far as the interpreter stuff, there are up to date patches I
> posted, but I didn't have time to commit. They might need a day or so
> of work & testing. If somebody feels lucky....

Do I need a life?  I'll sort those out this weekend (and resist the 
temptation to pick at another loose thread) and get them into current GDB.

This will mean that the pressure is on to quickly spin out a GDB 5.4 
containing the updates.

Nick,

These patches, among other things, add the new CLI command 
`interpreter'.  This command lets you do things like:

(gdb) interpreter mi -<mi-command> <mi-args>
.... mi output ...
(gdb)

and will allow EMACS to query GDB using the MI (breakpoint list, frame 
backtrace, ...) with out requiring a complete rewrite.

Assuming that the level-two annotations are largely needed for the CLI 
version of those, this in turn will make it possible for EMACS to 
migrate at least partially to MI and at the same time drop the only just 
added level-two annotations requirement.

Long term, it would be good if EMACS used the -mi interpreter by 
default, but I don't see that as an absolute requirement.

RMS has indicated that if I and you agree to finish the MI support that 
Emacs needs, and convert Emacs to use it, in a short time (say, three 
months), he would go along with that plan.

I do manage to cover the MI side this weekend, can you, with some help 
from a few other GDB / EMACS hackers, cover the EMACS side?

Andrew

Re: [Various] obsoleting the annotate level 2 interface

[Elena Zannoni]

Nick Roberts writes:
 > > On Wed, 29 Jan 2003 10:56:02 -0500, Christopher Faylor wrote:
 > > > On Wed, Jan 29, 2003 at 04:51:06PM +0100, Arnaud Charlet wrote:
 > > > > Honestly?  No.  MI has `kick ass' features sufficent to justify the
 > > > > move now:
 > 
 > > > Well fine, so we are in disagreement.  Maybe the gdb GUI you've written
 > > > does not have the same requirements than GVD has.
 > 
 > > > I'm not saying MI does not have some added value compared to CLI, I'm
 > > > just saying (and I'm not the only one) that there are some missing
 > > > features in MI which are important enough to be taken into account.
 > 
 > > And the missing features are...?
 > 
 > Well, the current online documentation at, 
 > http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC217,
 > says (summarised) :
 > 
 > Also note that the commands with a non-available example (N.A.) are not yet
 > implemented.
 > 
 > -display-delete                 N.A.
 > -display-disable                N.A.
 > -display-enable                 N.A.
 > -display-insert                 N.A.
 > -display-list                   N.A.
 > -exec-abort                     N.A.
 > -exec-show-arguments            N.A.
 > -file-list-exec-sections        N.A.
 > -file-list-exec-source-files    N.A.
 > -file-list-shared-libraries     N.A.
 > -file-list-symbol-files         N.A.
 > -stack-info-frame               N.A.
 > -symbol-info-address            N.A.
 > -symbol-info-file               N.A.
 > -symbol-info-function           N.A.
 > -symbol-info-line               N.A.
 > -symbol-info-symbol             N.A.
 > -symbol-list-functions          N.A.
 > -symbol-list-types              N.A.
 > -symbol-list-variables          N.A.
 > -symbol-locate                  N.A.
 > -symbol-type                    N.A.
 > -target-attach                  N.A.
 > -target-compare-sections        N.A.
 > -target-exec-status             N.A.
 > -target-list-available-targets  N.A.
 > -target-list-current-targets    N.A.
 > -target-list-parameters         N.A.
 > -thread-info                    N.A.
 > -thread-list-all-threads        N.A.
 > 
 > Ah, don't be fooled by the current online documentation... ;-)
 > 
 > Nick


I don't understand. The on line doc is up to date, it is not
lying. Those commands have not been implememted. We have gone through
3 projects (one internal to Cygnus, eclipse, and the apple ui) and
none of those missing commands was obviously a show stopper. Of course
those are *new* GUIs and they can be less functional. Emacs cannot go
backwards because some commands are missing. Does emacs need these
commands? for instance, does emacs have a window that shows the
threads of the inferior?

But it is not hard to implement them. These are fairly simple, almost
wrappers.

As far as the interpreter stuff, there are up to date patches I
posted, but I didn't have time to commit. They might need a day or so
of work & testing. If somebody feels lucky....

elena

Re: [Various] obsoleting the annotate level 2 interface

[Nick Roberts]

> On Wed, 29 Jan 2003 10:56:02 -0500, Christopher Faylor wrote:
> > On Wed, Jan 29, 2003 at 04:51:06PM +0100, Arnaud Charlet wrote:
> > > Honestly?  No.  MI has `kick ass' features sufficent to justify the
> > > move now:

> > Well fine, so we are in disagreement.  Maybe the gdb GUI you've written
> > does not have the same requirements than GVD has.

> > I'm not saying MI does not have some added value compared to CLI, I'm
> > just saying (and I'm not the only one) that there are some missing
> > features in MI which are important enough to be taken into account.

> And the missing features are...?

Well, the current online documentation at, 
http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC217,
says (summarised) :

Also note that the commands with a non-available example (N.A.) are not yet
implemented.

-display-delete                 N.A.
-display-disable                N.A.
-display-enable                 N.A.
-display-insert                 N.A.
-display-list                   N.A.
-exec-abort                     N.A.
-exec-show-arguments            N.A.
-file-list-exec-sections        N.A.
-file-list-exec-source-files    N.A.
-file-list-shared-libraries     N.A.
-file-list-symbol-files         N.A.
-stack-info-frame               N.A.
-symbol-info-address            N.A.
-symbol-info-file               N.A.
-symbol-info-function           N.A.
-symbol-info-line               N.A.
-symbol-info-symbol             N.A.
-symbol-list-functions          N.A.
-symbol-list-types              N.A.
-symbol-list-variables          N.A.
-symbol-locate                  N.A.
-symbol-type                    N.A.
-target-attach                  N.A.
-target-compare-sections        N.A.
-target-exec-status             N.A.
-target-list-available-targets  N.A.
-target-list-current-targets    N.A.
-target-list-parameters         N.A.
-thread-info                    N.A.
-thread-list-all-threads        N.A.

Ah, don't be fooled by the current online documentation... ;-)

Nick