From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7761 invoked by alias); 22 Jan 2003 08:37:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7752 invoked from network); 22 Jan 2003 08:37:02 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by 172.16.49.205 with SMTP; 22 Jan 2003 08:37:02 -0000 Received: from laocoon.ics.u-strasbg.fr (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (Postfix) with ESMTP id 890FF2C26C0 for ; Wed, 22 Jan 2003 09:59:24 +0100 (CET) Message-Id: <5.0.2.1.2.20030122091840.00ae8408@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Wed, 22 Jan 2003 08:37:00 -0000 To: gdb@sources.redhat.com From: Pierre Muller Subject: Re: obsoleting the annotate level 2 interface In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2003-01/txt/msg00368.txt.bz2 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.