Re: obsoleting the annotate level 2 interface

Re: obsoleting the annotate level 2 interface

[Michael Elizabeth Chastain]

Andrew C asks:
> What of the other potential clients (DDD, ...)?

I glanced at DDD.  The most recent DDD is DDD 3.3.1, released 2001-05-02.
It has a "-fullname" option which it passes down to gdb.  ddd/GDBAgent.c
has code to discard any annotation-2 output coming from gdb:

  # ddd/GDBAgent.c
  case '\032':
      // In annotation level 2, GDB sends out `annotation'
      // sequences like `\n\032\032prompt\n'.  Future DDD
      // versions might want to look at these annotations; right
      // now, we simply weed them out.

There's similar code for the annotation-2 prompt.  I didn't see any code
in DDD 3.3.1 to turn on annotation, it just wants to ignore any
annotation-2 that the user turns on.

The CVS version of ddd/GDBAgent.c (from sourceforge) still has this code.

http://www.gnu.org/software/ddd has links to several other front ends,
including: gvd, insight, kdbg, xxgdb, tgdb, xwpe.

Let me know if it would be useful to chase all these projects down and
report on them.

Michael C

Re: obsoleting the annotate level 2 interface

[Arnaud Charlet]

Concerning gvd, we rely on -fullname (aka set annotate 1), not annotate 2,
so this change would be ok with us.

Arno

Re: obsoleting the annotate level 2 interface

[Andrew Cagney]

> I would like to reiterate the points that many have made thus far.

Sorry, not that many.  A few have expressed concerns but I believe that 
those concerns have been addressed.

> Existing applications depend on annotate level 1 (ddd, gvd, ...) and 
> level 2 (emacs, cgdb).

All released versions of EMACS use level-one annotations.  Only an 
unreleased development uses level-two.  Plans are underway to migrate 
that away from level-two.

>  Until the MI interface is complete (supports 
> CLI and GDB user output) and all existing applications have made 


> the switch to using the MI, the annotations cannot be removed.  
> My current understanding is that GDB/MI is not a completely viable 
> alternative for these GDB interfaces to use to replace annotate 1 or 
> 2.  Therefore, the annotations -- while being deprecated -- must be 
> retained in future releases until the GDB/MI is capable of 
> supporting these applications.

The changes are sitting on the:
	interps-20030201-branch
I've just reviewed and cleaned them up - now pass without regressions. 
So commit is tomorrow.

Andrew

Re: obsoleting the annotate level 2 interface

[Mike Mueller]

Andrew Cagney wrote:

> I don't think that is sufficient - making something deprecated 
> only tells the user that they should not use it in new 
> development.  Not that they must rewrite existing code to not 
> use it.  To do that we'd have to  obsolete it.  (Asside, this is 
> the same as for code - deprecating a  function only stops it 
> being used in new code.)
 
> I think something needs to be done to the next release that `rubs 
> the  users nose in it'.

> Andrew

I would like to reiterate the points that many have made thus far.

Existing applications depend on annotate level 1 (ddd, gvd, ...) and 
level 2 (emacs, cgdb).  Until the MI interface is complete (supports 
CLI and GDB user output) and all existing applications have made 
the switch to using the MI, the annotations cannot be removed.  
My current understanding is that GDB/MI is not a completely viable 
alternative for these GDB interfaces to use to replace annotate 1 or 
2.  Therefore, the annotations -- while being deprecated -- must be 
retained in future releases until the GDB/MI is capable of 
supporting these applications.

Mike

(CGDB developer -- http://cgdb.sourceforge.net)

Re: obsoleting the annotate level 2 interface

[Andrew Cagney]

> Nick Clifton <nickc@redhat.com> writes:

Er, Nick didn't.  I did :-)   Jim, there is something weird about your 
mailer (unless it's mine...).

>> > Also gdb-ui.el probably doesn't need all the annotations. If you lost some key
>> > ones (frames-invalid and breakpoints-invalid, for example) would this make it
>> > easier to maintain?
> 
>> 
>> Can you wind the code back to level-one annotations?  Remember, it is
>> level-two annotations that are causing all the grief?
> 
> 
> Well, gdb-ui provides a breakpoint window, a displays window, a local
> variables window,etc.  Level one just gives you enough to put an arrow
> in the source code.

I don't know that these need level-two annotations.  The bulk of the 
work is custom parsing of GDB's CLI output.

Andrew

Re: obsoleting the annotate level 2 interface

[Arnaud Charlet]

> Well, gdb-ui provides a breakpoint window, a displays window, a local
> variables window,etc.  Level one just gives you enough to put an arrow
> in the source code.

If you look at DDD and GVD that both provide more than gdb-ui, you'll see
that annotate 1 can be enough, although admitedly, things can be cumbersome
some times.

Arno

Re: obsoleting the annotate level 2 interface

[Jim Blandy]

Nick Clifton <nickc@redhat.com> writes:

> > Also gdb-ui.el probably doesn't need all the annotations. If you lost some key
> > ones (frames-invalid and breakpoints-invalid, for example) would this make it
> > easier to maintain?
> 
> Can you wind the code back to level-one annotations?  Remember, it is
> level-two annotations that are causing all the grief?

Well, gdb-ui provides a breakpoint window, a displays window, a local
variables window,etc.  Level one just gives you enough to put an arrow
in the source code.

Re: obsoleting the annotate level 2 interface

[Jim Blandy]

Nick Clifton <nickc@redhat.com> writes:
> I think writing a mode for Emacs that uses MI would require quite a different
> approach to gdb-ui.el. Think of what was involved in `bringing GDB over to MI'
> (a lot of work, I would imagine).

I don't think it will be too bad.  After all, with MI GDB provides all
the same information, but in a reliably parseable form.  I would
expect a good amount of hair in gdb-ui.el to go away.

> At the time, streams didn't seem to work. I couldn't seem to generate the @
> prefix output. That's probably changed now. I can't really say much more
> until I have something concrete to experiment with.

Probably the most recent release (GDB 5.3) is a good place to start.

> I have never seen the source for GDB. Perhaps you can explain why
> annotations is difficult to maintain. In my limited experience, I
> have found that two features in a program can often be orthogonal to
> one another. That is, one feature can be developed as if the other
> feature isn't there.

Well, I talked about this a bit in my original post.  Three reasons:

- Both annotations and MI involve little changes sprinkled throughout
  GDB's code: every command that produces output has to be marked up.
  (This isn't the whole story; with MI, we often just add new commands
  that have more disciplined behavior for a program to use.)  We don't
  want to have to maintain both of those systems, when one of them is
  good enough to do the job.

- MI is more stable.  Annotation simply flags pieces of GDB's ordinary
  output to suggest where a consumer might start parsing --- but the
  data being parsed is GDB's direct output.  This means that any time
  we change the way GDB prints something --- say, to make something
  clearer, or to provide newly available information --- we may break
  clients trying to parse that output.  There's history to show that
  this is a problem.

  With MI, however, there's a much clearer segregation between the
  information intended for machine consumption, and that intended only
  for human consumption --- data that isn't yet available in a nicely
  parsed form, or presumably isn't interesting to other programs.
  They're produced using distinct calls.  So for a GDB developer, it's
  much clearer when you're changing something that another program
  might care about.

- MI can age more gracefully than annotations can.  With annotations,
  it's never clear to a GDB developer exactly which information other
  programs are consuming, and which they don't care about.  MI is
  designed so that, when you discover something a program needs, it's
  easy to rework the output code (or write some new output code) to
  produce it in MI form --- so MI's capabilities can grow in an
  evolutionary, organic kind of way, without breaking things all the
  time.

Really, once you get things going with MI, I think you'll prefer it.

> Also gdb-ui.el probably doesn't need all the annotations. If you
> lost some key ones (frames-invalid and breakpoints-invalid, for
> example) would this make it easier to maintain?

Well, but if gdb-ui takes off, people will want to add more and more
features to it.  That's what we all hope for, right?  You don't want
your success case to be the one that you've promised to avoid.

Like you, I don't have time officially allocated for this.  So we'll
both need to be patient with each other.  But Emacs is the only
environment that I can imagine using, and I use GDB in Emacs daily, so
I'm interested in doing what I can to make this work out.

Re: obsoleting the annotate level 2 interface

[Andrew Cagney]

> Also gdb-ui.el probably doesn't need all the annotations. If you lost some key
> ones (frames-invalid and breakpoints-invalid, for example) would this make it
> easier to maintain?

Can you wind the code back to level-one annotations?  Remember, it is 
level-two annotations that are causing all the grief?

Andrew

Re: obsoleting the annotate level 2 interface

[Andrew Cagney]

> I think this is what has baffled a lot of GDB users. There are something like
> 39 problem reports open for MI and only 14 closed (I'm hesitant to say this as
> I applaud the transparency of the system and I don't want to encourage
> secrecy). We don't see how the GDB developers can deprecate annotations or
> encourage users to switch to MI until it is ready.

Ah, don't be fooled by statistics.  GDB has 600 open `bugs' (out of 900) 
yet GDB still works pretty well.

Rather than look at the bugs, look at the MI testsuite and all the cases 
it verifies as working correctly.

Andrew

Re: obsoleting the annotate level 2 interface

[Nick Roberts]

 > Nick, what is involved in bringing gdb-ui over to using MI?

A dialogue is a good starting point. I'm slightly surprised at the
lack of communication between GDB and Emacs developers given the common
heritage.

I think writing a mode for Emacs that uses MI would require quite a different
approach to gdb-ui.el. Think of what was involved in `bringing GDB over to MI'
(a lot of work, I would imagine).

 > Annotations have been deprecated for a while now, so it probably won't
 > kill us to keep them for a while longer, but it doesn't make sense for
 > us to keep them indefinitely; gdb-ui needs to start making the
 > transition.

I think this is what has baffled a lot of GDB users. There are something like
39 problem reports open for MI and only 14 closed (I'm hesitant to say this as
I applaud the transparency of the system and I don't want to encourage
secrecy). We don't see how the GDB developers can deprecate annotations or
encourage users to switch to MI until it is ready.

For my part, I will start to look at MI again. It appears that it has undergone
a lot of development since I looked at it last year. GDB developers could
help this process (not just for me, but all users) by ensuring that the
documentation for MI is bang up to date.

 >                                                      But from what I
 > do understand, I really think MI is the way GDB should go. 

I think everyone accepts this. It is just the timing that is being questioned.

 > Personally, I want a command-line interface to GDB too; I'd like to
 > see MI used to improve that (say, by handling 'display' or the
 > breakpoint list better), but I don't want to replace it.  What is MI
 > missing in this regard?  It seems to me like it's all there:
 > 
 >   zenia:emacs$ $D6/gdb/gdb --interpreter=mi2 $D6/gdb/gdb
 >   ~"GNU gdb 2003-01-23-cvs\n"
 >   ...

I've only looked at GDB 5.0 (GNU gdb 20010813 (MI_OUT)). It doesn't seem to
have mi2. I didn't spend much time looking at MI, I'm just one person,
dabbling in my spare time. I saw that annotations did what I wanted and I ran
with it. I don't think that I could have taken MI as far with such limited
resources.

 > What are the other issues?

At the time, streams didn't seem to work. I couldn't seem to generate the @
prefix output. That's probably changed now. I can't really say much more
until I have something concrete to experiment with.

 > This may not be the largest issue, but one thing that might be of
 > interest is that, given the way the MI support is done, it would be
 > very easy to have GDB provide all its output as Emacs Lisp
 > s-expressions, so Emacs could just 'read' them directly.  And this
 > would be a modular and relatively small change.  All you need to do is
 > provide your own `struct ui_out_impl' that prints things the way you
 > like.

I don't know what form it should take but I do think that GDB should hook into
Emacs in some way and that they appear to have drifted apart.

I have never seen the source for GDB. Perhaps you can explain why annotations
is difficult to maintain. In my limited experience, I have found that two 
features in a program can often be orthogonal to one another. That is, one
feature can be developed as if the other feature isn't there. 

Also gdb-ui.el probably doesn't need all the annotations. If you lost some key
ones (frames-invalid and breakpoints-invalid, for example) would this make it
easier to maintain?

Nick

Re: obsoleting the annotate level 2 interface

[Jim Blandy]

Nick, what is involved in bringing gdb-ui over to using MI?
Annotations have been deprecated for a while now, so it probably won't
kill us to keep them for a while longer, but it doesn't make sense for
us to keep them indefinitely; gdb-ui needs to start making the
transition.

Keep in mind, I haven't been taking part of all these conversations
about MI, Eclipse, and the rest, so I don't know the whole history of
what was broken when, who was unhelpful to whom, etc.  But from what I
do understand, I really think MI is the way GDB should go.  I'd like
to help make that happen.

Personally, I want a command-line interface to GDB too; I'd like to
see MI used to improve that (say, by handling 'display' or the
breakpoint list better), but I don't want to replace it.  What is MI
missing in this regard?  It seems to me like it's all there:

  zenia:emacs$ $D6/gdb/gdb --interpreter=mi2 $D6/gdb/gdb
  ~"GNU gdb 2003-01-23-cvs\n"
  ~"Copyright 2003 Free Software Foundation, Inc.\n"
  ~"GDB is free software, covered by the GNU General Public License, and you are\n"
  ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
  ~"Type \"show copying\" to see the conditions.\n"
  ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
  ~"This GDB was configured as \"i686-pc-linux-gnu\"..."
  ~"\n"
  (gdb)
  break symfile.c:1234
  &"break symfile.c:1234\n"
  ^done
  (gdb)
  print annotation_level
  &"print annotation_level\n"
  ~"$1 = 0"
  ~"\n"
  ^done
  (gdb)

In other words, you can just send the user's input to an MI GDB
directly, and whatever you get back prefixed with a ~ is what should
go into the interaction buffer as GDB's output.

One problem is that even command-line commands produce output in MI
style: whether I say "info breakpoints" (the CLI command) or
"-break-list" (the MI command), I get MI-style output:

    (gdb)
    -break-list
    ^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x080b183c",func="symbol_file_command",file="/home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/symfile.c",line="1234",times="0"}]}
    (gdb)
    info breakpoints
    &"info breakpoints\n"
    ^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="3",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x080b183c",func="symbol_file_command",file="/home/jimb/cygnus/src/sourceware/gdb/main/src/gdb/symfile.c",line="1234",times="0"}]}
    (gdb)

But I think this could be handled by having a cli ui_out stream built
on top of the default MI ui_out stream, and setting the global uiout
to that while running a command-line command.  That way, you'd get
CLI-style output wrapped up as an MI-style ~ packet.

For completion, can't gdb-ui.el continue to use the "complete"
command, just as Emacs always has?

  (gdb)
  complete break symfi
  &"complete break symfi\n"
  ~"break symfile_bfd\n"
  ~"break symfile_bfd_open\n"
  ~"break symfile_complaint_book\n"
  ~"break symfile_complaints\n"
  ~"break symfile_explanations\n"
  ~"break symfile_objfile\n"
  ~"break symfile_relocatable\n"
  ^done
  (gdb)

There's also the issue of having the program's output interleaved with
GDB's.  But you can use GDB's `tty' command to send the inferior's
output to any pseudotty you like --- you could put it in a separate
buffer from the GDB interaction, or you could copy it into the GDB
interaction buffer if that's what you want.

What are the other issues?

This may not be the largest issue, but one thing that might be of
interest is that, given the way the MI support is done, it would be
very easy to have GDB provide all its output as Emacs Lisp
s-expressions, so Emacs could just 'read' them directly.  And this
would be a modular and relatively small change.  All you need to do is
provide your own `struct ui_out_impl' that prints things the way you
like.

Re: obsoleting the annotate level 2 interface

[Andrew Cagney]

> Jim Blandy writes:
> 
>> 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.
> 
> 
> According to the NEWS file in gdb 5.1, the annotation interface
> is deprecated.  So I say, go for it!

I don't think that is sufficient - making something deprecated only 
tells the user that they should not use it in new development.  Not that 
they must rewrite existing code to not use it.  To do that we'd have to 
obsolete it.  (Asside, this is the same as for code - deprecating a 
function only stops it being used in new code.)

I think something needs to be done to the next release that `rubs the 
users nose in it'.

Andrew

Re: obsoleting the annotate level 2 interface

[Elena Zannoni]

Pierre Muller writes:
 > At 08:32 21/01/2003, Jim Blandy wrote:
 > 
 > >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.
 > 
 > 
 > I don't really understand the final implications of this removal:
 > 
 > -  the GDB support inside the FP IDE
 > (Free Pascal Integrated Development Editor)
 > is done by specific implementation of all the
 > annotate_XXX functions defined in annotate.h.
 > 
 > Are you going to remove all these functions?
 > Because the annotate.c almost empty
 > if we remove all code that has
 > 'if (annotation_level > 1) '
 > apart from some annotation hooks...
 > 
 > I am not against moving to MI, but I still didn't find the time to do it....
 > Where can I find a clean example of an implementation of gdb that
 > only uses mi functions (is insight mi clean?).
 > 

No, insight doesn't use MI. Apple's Project Builder does, I think the sources
are available on their web site. Alternatively, look at www.eclipse.org,
their cdt uses MI.

 >  I still do not undersantd clearly the difference between 
 > cli and mi, is that explained in the docs?
 > I didn't find anything about MI interface in gdbint doc.
 > 

Wrong manual, it is in the gdb users manual:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_25.html#SEC217


Elena

Re: obsoleting the annotate level 2 interface

[Pierre Muller]

At 08:32 21/01/2003, Jim Blandy wrote:

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


I don't really understand the final implications of this removal:

-  the GDB support inside the FP IDE
(Free Pascal Integrated Development Editor)
is done by specific implementation of all the
annotate_XXX functions defined in annotate.h.

Are you going to remove all these functions?
Because the annotate.c almost empty
if we remove all code that has
'if (annotation_level > 1) '
apart from some annotation hooks...

I am not against moving to MI, but I still didn't find the time to do it....
Where can I find a clean example of an implementation of gdb that
only uses mi functions (is insight mi clean?).

 I still do not undersantd clearly the difference between 
cli and mi, is that explained in the docs?
I didn't find anything about MI interface in gdbint doc.

Re: obsoleting the annotate level 2 interface

[Michael Elizabeth Chastain]

David C writes:
> (I don't want to delete them from that file until the whole file is gone,
> but I do want to reproduce the bugs in other files.)

That's my preference too.  Some day I'll be comparing gdb-5.3 to
the gdb 5.4/6.0 release candidate, and this way makes the comparison
either.

> I think I have a patch around to reproduce the watchpoint bug in
> gdb.base/watchpoint.exp; I'll polish that off and submit it.

Sounds good, I'll have my test bed ready for it.

I'll work on the infamous "annotate-quit" test.  I suppose that belongs
in gdb.base/interrupt.exp.

Michael C

Re: obsoleting the annotate level 2 interface

[David Carlton]

On Tue, 21 Jan 2003 11:41:51 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> gdb.c++/annota2.exp reports two KFAIL's which are unrelated to
> annotation.  One KFAIL is about a hardware watchpoint that triggers on
> the first instruction after resuming a breakpoint.  The other is about
> sending a ^C and then immediately reading from gdb (I suspect there is a
> race condition here but I'm not sure).  Actually it would be good to
> move those tests to a different test script right now, because it's such
> a pain to work with an annotation-enabled test script.

Yeah: it's silly to have bugs that only occur in gdb.c++/annota2.exp
and that have nothing to do with C++ or with annotation.  (I don't
want to delete them from that file until the whole file is gone, but I
do want to reproduce the bugs in other files.)  I think I have a patch
around to reproduce the watchpoint bug in gdb.base/watchpoint.exp;
I'll polish that off and submit it.

David Carlton
carlton@math.stanford.edu

Re: obsoleting the annotate level 2 interface

[Eli Zaretskii]

> From: Jim Blandy <jimb@redhat.com>
> Date: 21 Jan 2003 02:32:01 -0500
> 
> 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?

It's possible that RHIDE, the Turbo-C compatible IDE developed for
DJGPP, uses "annotate 2" (RHIDE has the GDB core built into it).  I CC
the DJGPP developers' mailing list, in the hope that someone who knows
more than myself about the debugging engine of RHIDE will tell whether
I'm wrong.

Re: obsoleting the annotate level 2 interface

[Jim Ingham]

Does anybody know what DDD uses?  It seems a logical client for the 
more detailed annotations, and it would be a shame to break it.

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

Re: obsoleting the annotate level 2 interface

[Michael Elizabeth Chastain]

Jim Blandy writes:
> 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.

According to the NEWS file in gdb 5.1, the annotation interface
is deprecated.  So I say, go for it!

There is one PR open against annotation level 2: pr gdb/785.  I think we
can quash it if we remove annotation level 2.  I sent mail to the
submitter, rros7605@postoffice.uri.edu, about other matter (pr gdb/786)
on 2003-01-01 and haven't heard back from them, so they probably don't
care.  And if we remove annotation level 2, then we don't care.

gdb.c++/annota2.exp reports two KFAIL's which are unrelated to
annotation.  One KFAIL is about a hardware watchpoint that triggers on
the first instruction after resuming a breakpoint.  The other is about
sending a ^C and then immediately reading from gdb (I suspect there is a
race condition here but I'm not sure).  Actually it would be good to
move those tests to a different test script right now, because it's such
a pain to work with an annotation-enabled test script.

I've made a note in my TODO list to do that.

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

emacs invokes gdb with "gdb -fullname" so it's just our gdb code which
maps that to "annotate level 1".  We can continue to do the same
behavior and just call it the "fullname" flag instead of the
"annotation" flag.

It looks a bit hard to remove the behavior, because lisp/gud.el
interacts with many different debuggers.  I suppose it would be nice to
have a new emacs gdb interface which takes full advantage of MI, but
that would not make lisp/gud.el obsolete, so the "-fullname" behavior
would not be obsolete.

Michael C

Re: obsoleting the annotate level 2 interface

[David Carlton]

On 21 Jan 2003 02:32:01 -0500, Jim Blandy <jimb@redhat.com> said:

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

While we're at it, we should also obsolete gdb -epoch and the
'inspect' command.  (See PR gdb/614.)

David Carlton
carlton@math.stanford.edu

Re: obsoleting the annotate level 2 interface

[Andrew Cagney]

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

Hmm, yes!  Dead code elimination is always good.
Removing the annotate stuff was always part of MI's long term agenda.

> Some background: the 'set annotate' command sets the
> 'annotation_level' variable.  There are only three distinguished
> values for this variable:

Can you perhaps do a little more research into the history of this 
feature?   For instance, was this initially part of some now abandoned 
project, or was this just `a good idea at the time'?  What of the other 
potential clients (DDD, ...)?  This helps strengthen the non-technical 
rationale for this user interface change.

As for implementing this, the first step is pretty easy, just tweak 
"main.c" to print a warning when level 2 is selected.  (Like the 
`deprecate mechanism we've got for commands'.)

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

Yes.  RMS has previously inidicated his liking of the idea of having 
EMACS use MI.  The lack of a console was identified as a technical 
barrier to that change :-/

Andrew

obsoleting the annotate level 2 interface

[Jim Blandy]

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