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: Eli Zaretskii <eliz at gnu dot org>
- To: pmuldoon at redhat dot com
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 30 Sep 2010 16:43:43 +0200
- Subject: Re: [patch] Add visible flag to breakpoints.
- References: <m38w2j72jd.fsf@redhat.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Phil Muldoon <pmuldoon@redhat.com>
> Date: Thu, 30 Sep 2010 15:02:14 +0100
>
> 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'.
What will happen if there's some low-level failure in inserting such a
breakpoint? Won't GDB display an error message citing a breakpoint
that "doesn't exist", as far as the user is concerned?
> -defaults to @code{BP_BREAKPOINT}. The optional @var{wp_class}
> +defaults to @code{BP_BREAKPOINT}. The optional @var{visible} argument
> +allows the breakpoint to become invisible to the user. The breakpoint
> +will neither be reported when created, or will it be enumerated in the
^^
"nor" should be used here.
Also, consider using "listed" or "shown" instead of "enumerated". I
think the former 2 alternatives make the text easier to read without
losing anything.
> +output from @samp{info breakpoints} (but will be enumerated with the
> +@samp{maint info breakpoints} command).
I believe we use @code markup for commands, not @samp.
> +@defivar Breakpoint visible
> +This attribute holds the breakpoint's visibility flag --- the identifier used to
^^^^^
No spaces are needed around the em-dash.
Okay with those changes.
Thanks.