From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31761 invoked by alias); 3 Jun 2008 05:08:43 -0000 Received: (qmail 31753 invoked by uid 22791); 3 Jun 2008 05:08:43 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jun 2008 05:08:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 11EF02A96E2; Tue, 3 Jun 2008 01:08:23 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gyckHbfn4uKS; Tue, 3 Jun 2008 01:08:22 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C24BB2A969D; Tue, 3 Jun 2008 01:08:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9299EE7ACD; Mon, 2 Jun 2008 22:08:18 -0700 (PDT) Date: Tue, 03 Jun 2008 05:08:00 -0000 From: Joel Brobecker To: Nick Roberts Cc: gdb-patches@sourceware.org, ghost@cs.msu.su Subject: Re: [PATCH:MI] Use observers for breakpoints Message-ID: <20080603050818.GA19062@adacore.com> References: <18498.3436.91443.361769@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18498.3436.91443.361769@kahikatea.snap.net.nz> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00012.txt.bz2 > Following Aleksandar Ristovski's patch for catchpoints in GDB/MI, > here's a patch to demonstrate the use of observers for breakpoints. > This relates to earlier patches I've submitted which uses event > notification to communicate a change in state rather than using > command output directly. Among other things this allows the use of > CLI commands with MI. I missed the earlier patch, but I think that the idea is sound. I suggest you change the observer profile to take a breakpoint rather than a breakpoint number, to avoid having going from the breakpoint number back to the breakpoint itself should an observer need it. I'm wondering if it might be useful to create two specific events for breakpoint created and deleted. Particularly for the "deleted" event, where you end up outputing the entire description of a breakpoint that is obsolete. Just as an aside, I don't know how others would feel about that, but I wouldn't mind seeing annotate.c:breakpoints_changed being renamed to annotate_breakpoints_changed. -- Joel