This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Add visible flag to breakpoints.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]