From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24505 invoked by alias); 31 Jan 2011 02:10:46 -0000 Received: (qmail 24394 invoked by uid 22791); 31 Jan 2011 02:10:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Jan 2011 02:10:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7767B2BABDB; Sun, 30 Jan 2011 21:10:39 -0500 (EST) 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 5Og1DrSkG0pK; Sun, 30 Jan 2011 21:10:39 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 04BF02BAB76; Sun, 30 Jan 2011 21:10:39 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 5F8F21459BF; Mon, 31 Jan 2011 06:10:33 +0400 (RET) Date: Mon, 31 Jan 2011 02:42:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: FYI: add some breakpoint setter methods Message-ID: <20110131021033.GC2384@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-01/txt/msg00573.txt.bz2 > As an aside, it seems to me that the breakpoint observers should > probably take a 'struct breakpoint *' as an argument, rather than a > breakpoint number. This would be more efficient: I think most users > will want to have access to the actual breakpoint anyhow, and this would > avoid a search through all breakpoints for the number. Perhaps I will > implement this. Seems like a good idea. I had a discussion like that with one of the contributors a while ago, trying to convince him to use a breakpoint struct instead of the breakpoint number in his observer. I think it was for annotations. In any case, he argued that this was sufficient for his needs so far, so I let it go, but it came back to "bite" me later on ("bite" <=> I had to change it to use struct breakpoint). > 2011-01-27 Tom Tromey > > * infcmd.c (finish_backward): Use breakpoint_set_silent. > * python/py-breakpoint.c (bppy_set_silent): Use > breakpoint_set_silent. > (bppy_set_thread): Use breakpoint_set_thread. > (bppy_set_task): Use breakpoint_set_task. > * breakpoint.h (breakpoint_set_silent, breakpoint_set_thread) > (breakpoint_set_task): Declare. > (make_breakpoint_silent): Remove. > * breakpoint.c (breakpoint_set_silent): New function. > (breakpoint_set_thread): Likewise. > (breakpoint_set_task): Likewise. > (make_breakpoint_silent): Remove. Just a nit I noticed: > +/* Set the internal `silent' flag on the breakpoint. Note that this > + is not the same as the "silent" that may appear in the breakpoint's > + commands. */ > + > +void > +breakpoint_set_silent (struct breakpoint *b, int silent) > +{ > + int old_silent = b->silent; > + b->silent = silent; Missing empty line after variable declaration (it's happening multiple times throughout the patch). -- Joel