This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: obsoleting the annotate level 2 interface
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