From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23273 invoked by alias); 30 Sep 2010 14:43:08 -0000 Received: (qmail 23261 invoked by uid 22791); 30 Sep 2010 14:43:07 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 30 Sep 2010 14:43:00 +0000 Received: (qmail 22134 invoked from network); 30 Sep 2010 14:42:58 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Sep 2010 14:42:58 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, pmuldoon@redhat.com Subject: Re: [patch] Add visible flag to breakpoints. Date: Thu, 30 Sep 2010 17:04:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009301542.57057.pedro@codesourcery.com> 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: 2010-09/txt/msg00512.txt.bz2 On Thursday 30 September 2010 15:02:14, Phil Muldoon wrote: > This is part of a larger effort to improve the Python breakpoint support > within GDB. One of the use-cases we have in Python is for a command to > set (maybe a large) number of breakpoints to catch predefined > behavior. However we do not want this to impact the usability or > readability of the existing 'info breakpoints' output. This patch fixes > that by allowing breakpoints to become invisible to the user. (...) > Currently this visibility flag is only accessible through the Python > breakpoint code. If the visible keyword is set when the breakpoint is > created, it will not be mentioned (only the new breakpoint observer will > be called), and the breakpoint will not be enumerated via 'info > breakpoints'. The visibility of a breakpoint can subsequently be > altered via the 'visible' attribute of the Python object which will flip > the visible flag in the breakpoint struct. Subsequent calls to 'info > breakpoints' will then show the breakpoint. There are several > assumptions I have made in this patch. Can you give an example of a use case where you would want to be able to show/hide breakpoints from the user _after_ they've been created? This looks like something that has potential to confuse users. E.g., "my gdb sometimes creates breakpoint 10 and then skips to create breakpoint 20, what gives? where are 11-19?". If toggling the new visible attribute isn't really necessary, did you consider instead a new "internal-or-not-internal" flag to the breakpoint constructor? An internal breakpoint is just a breakpoint with number < 0, and as such is not visible to the user. ? As is, your patch does not consider for example the "delete" command --- it wipes all non-internal breakpoints, even if hidden! That's potential for breaking the python client code that creates and manages such breakpoints. I suggest you go through breakpoint.c and inspect all checks against b->number < 0 or b->number >= 0. > (create_new_breakpoint): Renamed from create_new_breakpoint. Add > visible parameter. Renamed from create_breakpoint. > +# Test invisible breakpooints. Typo. -- Pedro Alves