Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: [Various] obsoleting the annotate level 2 interface
@ 2003-01-31 20:14 Nick Roberts
  2003-01-31 20:56 ` Elena Zannoni
  0 siblings, 1 reply; 26+ messages in thread
From: Nick Roberts @ 2003-01-31 20:14 UTC (permalink / raw)
  To: gdb

> 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


^ permalink raw reply	[flat|nested] 26+ messages in thread
[parent not found: <1044050405.3227.ezmlm@sources.redhat.com>]
* [Various] obsoleting the annotate level 2 interface
@ 2003-01-28 20:05 Jim Blandy
  2003-01-28 20:36 ` Andrew Cagney
  2003-01-28 22:29 ` Arnaud Charlet
  0 siblings, 2 replies; 26+ messages in thread
From: Jim Blandy @ 2003-01-28 20:05 UTC (permalink / raw)
  To: gdb

[-- 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






^ permalink raw reply	[flat|nested] 26+ messages in thread
end of thread, other threads:[~2003-02-01 16:16 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-31 20:14 [Various] obsoleting the annotate level 2 interface Nick Roberts
2003-01-31 20:56 ` Elena Zannoni
2003-01-31 21:10   ` Andrew Cagney
     [not found]     ` <15931.6572.456534.588251@nick.uklinux.net>
     [not found]       ` <15931.8581.923838.921739@localhost.redhat.com>
2003-02-01 16:16         ` Nick Roberts
2003-01-31 22:33   ` Nick Roberts
2003-02-01  4:13   ` Jim Blandy
     [not found] <1044050405.3227.ezmlm@sources.redhat.com>
2003-02-01  0:43 ` Jim Ingham
  -- strict thread matches above, loose matches on Subject: below --
2003-01-28 20:05 Jim Blandy
2003-01-28 20:36 ` Andrew Cagney
2003-01-29  6:14   ` Eli Zaretskii
2003-01-29 21:56     ` Jim Blandy
2003-01-28 22:29 ` Arnaud Charlet
2003-01-29  5:38   ` Andrew Cagney
2003-01-29  8:55     ` Arnaud Charlet
2003-01-29 15:19       ` Andrew Cagney
2003-01-29 15:31         ` Arnaud Charlet
2003-01-29 15:43           ` Andrew Cagney
2003-01-29 15:51             ` Arnaud Charlet
2003-01-29 15:55               ` Christopher Faylor
2003-01-29 16:01                 ` Arnaud Charlet
2003-01-29 16:19                   ` Andrew Cagney
2003-01-29 16:34                     ` Arnaud Charlet
2003-01-29 17:16                       ` Andrew Cagney
2003-01-29 19:03                       ` Tom Tromey
2003-01-29 22:38                         ` Jim Blandy
2003-01-29 17:19         ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox