This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Add visible flag to breakpoints.
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: gdb-patches at sourceware dot org
- Cc: dan at codesourcery dot com
- Date: Thu, 30 Sep 2010 17:18:15 +0100
- Subject: Re: [patch] Add visible flag to breakpoints.
- References: <m38w2j72jd.fsf@redhat.com> <20100930144132.GA15652@caradoc.them.org>
- Reply-to: pmuldoon at redhat dot com
Daniel Jacobowitz <dan@codesourcery.com> writes:
> On Thu, Sep 30, 2010 at 03:02:14PM +0100, 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.
>
> How does this interact with GDB-internal breakpoints (those with
> negative numbers)? If you didn't need to switch visibility at
> runtime, you could just create these as internal.
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. 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.
Cheers
Phil