From: Pedro Alves <pedro@codesourcery.com>
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 [thread overview]
Message-ID: <201009301542.57057.pedro@codesourcery.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2010-09-30 14:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-30 16:28 Phil Muldoon
2010-09-30 16:41 ` Daniel Jacobowitz
2010-09-30 17:51 ` Phil Muldoon
2010-09-30 17:55 ` Pedro Alves
2010-09-30 18:12 ` Phil Muldoon
2010-10-08 12:51 ` Phil Muldoon
2010-10-08 13:35 ` Pedro Alves
2010-10-08 14:04 ` Phil Muldoon
2010-10-08 18:44 ` Tom Tromey
2010-10-12 20:25 ` Phil Muldoon
2010-10-12 21:34 ` Tom Tromey
2010-10-13 12:45 ` Phil Muldoon
2010-10-13 13:06 ` Phil Muldoon
2010-10-13 15:36 ` Tom Tromey
2010-10-16 18:42 ` Pedro Alves
2010-10-16 19:03 ` Pedro Alves
2010-10-18 16:09 ` Tom Tromey
2010-10-22 21:05 ` Phil Muldoon
2010-10-22 21:31 ` Eli Zaretskii
2010-10-22 21:37 ` Phil Muldoon
2010-10-23 9:07 ` Eli Zaretskii
2010-10-31 21:07 ` Pedro Alves
2010-11-11 14:36 ` Phil Muldoon
2010-11-12 12:43 ` Ken Werner
2010-11-12 12:49 ` Pedro Alves
2010-11-12 12:58 ` Ken Werner
2010-10-08 18:40 ` Tom Tromey
2010-09-30 17:04 ` Pedro Alves [this message]
2010-09-30 17:55 ` Phil Muldoon
2010-09-30 17:51 ` Eli Zaretskii
2010-10-05 22:28 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201009301542.57057.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=pmuldoon@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox