From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5163 invoked by alias); 30 Sep 2010 16:41:43 -0000 Received: (qmail 5020 invoked by uid 22791); 30 Sep 2010 16:41:41 -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 16:41:35 +0000 Received: (qmail 21949 invoked from network); 30 Sep 2010 16:41:33 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Sep 2010 16:41:33 -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:55:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: dan@codesourcery.com References: <20100930144132.GA15652@caradoc.them.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009301741.32379.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/msg00516.txt.bz2 On Thursday 30 September 2010 17:18:15, Phil Muldoon wrote: > The original patch I wrote did use negative numbers for bp_breakpoint > type (in fact that patch is a commit in the archer branch: > archer-pmuldoon-python-breakpoints). But normal bp_breakpoints with a > negative number are still displayed with 'info breakpoints'. Currently > the visibility of breakpoints is not decided on their number but their > type. > breakpoint_1 tests for these in user_settable_breakpoint. I think that's just cruft and can be replaced by a b->number < 0 check? > All I > did in that aspect was to add an additional check for > breakpoint_visible. I decided that if displaying the breakpoint was > just an arbitrary check that I would introduce a visible flag and avoid > all the re-plumbing of numbers/negative numbers in create_breakpoint. > The plumbing would have been necessary because ... > > I also did look at create_internal_breakpoint, but those work on > a single address. We would either have the user translate the breakpoint to an > address with calls to decode_line or do it ourselves. I felt that a > flag would be better here than to duplicate this effort. Also there are > several cases/detections in generic bp_breakpoints that might be > useful for users of Python breakpoints. And finally to substantially change the > breakpoint mechanics underneath the call for a Python breakpoint purely > because one was created visible and the other not seemed counter-intuitive. I'm not sure what large effort you're thinking this entails. You've carried the "visible" flag as argument all the way down to create_breakpoint_sal already. So instead of: @@ -6961,6 +6973,7 @@ create_breakpoint_sal (struct gdbarch *gdbarch, b->enable_state = enabled ? bp_enabled : bp_disabled; b->disposition = disposition; b->pspace = sals.sals[0].pspace; + b->visible = visible; You change this: b = set_raw_breakpoint (gdbarch, sal, type); set_breakpoint_count (breakpoint_count + 1); b->number = breakpoint_count; to: b = set_raw_breakpoint (gdbarch, sal, type); if (visible /* or some other name, user? !internal? */) { set_breakpoint_count (breakpoint_count + 1); b->number = breakpoint_count; } else { b->number = internal_breakpoint_number--; } and you're golden. What am I missing? -- Pedro Alves