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: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org, pmuldoon at redhat dot com
- Date: Thu, 30 Sep 2010 15:42:56 +0100
- Subject: Re: [patch] Add visible flag to breakpoints.
- References: <m38w2j72jd.fsf@redhat.com>
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