Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: gdb@sources.redhat.com
Subject: obsoleting the annotate level 2 interface
Date: Tue, 21 Jan 2003 07:38:00 -0000	[thread overview]
Message-ID: <vt265sjj6vi.fsf@zenia.red-bean.com> (raw)


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).


             reply	other threads:[~2003-01-21  7:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-21  7:38 Jim Blandy [this message]
2003-01-21 16:15 ` Andrew Cagney
2003-01-21 16:54 ` David Carlton
2003-01-21 19:04 ` Eli Zaretskii
2003-01-22  8:37 ` Pierre Muller
2003-01-22 15:06   ` Elena Zannoni
     [not found] ` <15917.39229.935851.920452@nick.uklinux.net>
2003-01-28 20:51   ` Jim Blandy
2003-01-29  1:41     ` Nick Roberts
2003-01-29  5:37       ` Andrew Cagney
2003-01-29  5:40       ` Andrew Cagney
2003-01-29 21:58         ` Jim Blandy
2003-01-29 22:00           ` Arnaud Charlet
2003-01-29 22:50           ` Andrew Cagney
2003-01-29 21:52       ` Jim Blandy
2003-01-21 17:41 Michael Elizabeth Chastain
2003-01-21 20:25 ` David Carlton
2003-01-22 16:45 ` Andrew Cagney
2003-01-21 18:09 Michael Elizabeth Chastain
2003-01-22  7:56 ` Arnaud Charlet
     [not found] <1043140716.4941.ezmlm@sources.redhat.com>
2003-01-21 19:03 ` Jim Ingham
2003-01-21 20:40 Michael Elizabeth Chastain
2003-02-04  1:45 Mike Mueller
2003-02-04  6:58 ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=vt265sjj6vi.fsf@zenia.red-bean.com \
    --to=jimb@redhat.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox