From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13695 invoked by alias); 3 Jun 2008 22:48:41 -0000 Received: (qmail 13633 invoked by uid 22791); 3 Jun 2008 22:48:40 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jun 2008 22:48:06 +0000 Received: from kahikatea.snap.net.nz (152.62.255.123.dynamic.snap.net.nz [123.255.62.152]) by viper.snap.net.nz (Postfix) with ESMTP id C7FDE3D9F8D; Wed, 4 Jun 2008 10:48:02 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id C5BB08FC6D; Wed, 4 Jun 2008 10:47:55 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18501.51738.226990.896238@kahikatea.snap.net.nz> Date: Tue, 03 Jun 2008 22:48:00 -0000 To: Joel Brobecker Cc: gdb-patches@sourceware.org, ghost@cs.msu.su Subject: Re: [PATCH:MI] Use observers for breakpoints In-Reply-To: <20080603050818.GA19062@adacore.com> References: <18498.3436.91443.361769@kahikatea.snap.net.nz> <20080603050818.GA19062@adacore.com> X-Mailer: VM 7.19 under Emacs 22.2.50.2 X-IsSubscribed: yes 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/msg00018.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. Here's one reference: http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html Like Daniel says, the frame-changed notification would probably fire too often, but the thread-changed one still seems a good idea and I have submitted a patch to do this with annotations too: http://sourceware.org/ml/gdb-patches/2008-05/msg00611.html > 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. My observer just uses a function called breakpoint_query (based on gdb_breakpoint_query) which only needs the breakpoint number. I think this is an internal detail which could easily be changed should the need arise. > 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. Sure, it's just a sketch. There are three types of event: breakpoint_create_event breakpoint_modify_event breakpoint_delete_event I don't know if there's much to be gained in differentiating between creating and modifying a breakpoint but it would certainly make sense to have two observers, breakpoints_changed and breakpoints_deleted, say. If this patch goes in we could start dismantling the events mechanism. They're only used in a few other places, e.g, tracepoints, and presumably observers could be used there too. > 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. This function was moved from breakpoint.c. A couple of years ago I submitted a patch to remove this and some other annotations, just keeping the level three annotations. If we are going to keep it, I suggest calling it annotate_breakpoints_invalid after the name of the associated annotation and to be consistent with annotate_frames_invalid. -- Nick http://www.inet.net.nz/~nickrob