From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3494 invoked by alias); 21 Jun 2005 06:00:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3354 invoked by uid 22791); 21 Jun 2005 06:00:31 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 21 Jun 2005 06:00:31 +0000 Received: from farnswood.snap.net.nz (p181-tnt1.snap.net.nz [202.124.110.181]) by viper.snap.net.nz (Postfix) with ESMTP id CCA545437E4; Tue, 21 Jun 2005 18:00:25 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 74ADB62A99; Tue, 21 Jun 2005 06:38:29 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17079.42964.633253.582441@farnswood.snap.net.nz> Date: Tue, 21 Jun 2005 06:00:00 -0000 To: Bob Rossi Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Removal of markup annotations In-Reply-To: <20050621014127.GA2648@white> References: <17071.40307.949193.158796@farnswood.snap.net.nz> <20050615154057.GB20778@white> <17072.46112.23475.26195@farnswood.snap.net.nz> <20050615233529.GC21803@white> <17072.49436.811019.408854@farnswood.snap.net.nz> <20050621014127.GA2648@white> X-SW-Source: 2005-06/txt/msg00328.txt.bz2 > Well, it is not as easy for me to just parse the output without the > annotations. Since I am still going to use annotate=2 (we are not > depricating the whole thing, right?), then if you remove the breakpoints > markup I'll have to handle old GDB's that have the markup, and new GDB's > that don't. > > This would be a serious pain. Its not that hard to do. You have to filter the annotations in any case. Emacs in CVS works with --annotate=2 or --annotate=3. Lisp is ideally suited to this kind of thing, but I think it should be quite straightforward in C too. An association list stores a list of keys (the annotations) with an associated value (a function to call). There are no keys for the markup annotations so it just ignores them. > I really only need 3 annotations out of the ones you are removing. > breakpoint-table (to set a state that breakpoints are coming), field 5 > (which we could rename to breakpoint-at), and breakpoint-table-end (to > set a state that the breakpoints are over. > > To make things even easier, there could simply be a -breakpoint-begin, > and a -breakpoint-end annotation, and those two annotations could mark > up around the breakpoint. Would this clean up the code in breakpoint.c at > all? I don't think we should introduce new annotations. Until now I've never really looked at breakpoint.c. I've just submitted this patch to make it less likely that they all get removed when I'm not following the mailing list. If no-one else is interested in their removal, I will just submit another much smaller patch that removes the breakpoints-invalid and frames-invalid from level 3, which AFAIK only Emacs uses. Nick