From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4813 invoked by alias); 22 Jan 2003 15:06:47 -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 4803 invoked from network); 22 Jan 2003 15:06:47 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 22 Jan 2003 15:06:47 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0MEbvf02458 for ; Wed, 22 Jan 2003 09:37:57 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0MF6da08711 for ; Wed, 22 Jan 2003 10:06:39 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0MF6cb29739 for ; Wed, 22 Jan 2003 10:06:38 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 2FE5EFF79; Wed, 22 Jan 2003 10:11:05 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15918.46217.24159.144623@localhost.redhat.com> Date: Wed, 22 Jan 2003 15:06:00 -0000 To: Pierre Muller Cc: gdb@sources.redhat.com Subject: Re: obsoleting the annotate level 2 interface In-Reply-To: <5.0.2.1.2.20030122091840.00ae8408@ics.u-strasbg.fr> References: <5.0.2.1.2.20030122091840.00ae8408@ics.u-strasbg.fr> X-SW-Source: 2003-01/txt/msg00374.txt.bz2 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