This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH] python doc: Rework Breakpoint.__init__ doc
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: <gdb-patches at sourceware dot org>
- Cc: Simon Marchi <simon dot marchi at ericsson dot com>
- Date: Thu, 7 Dec 2017 16:23:19 -0500
- Subject: [PATCH] python doc: Rework Breakpoint.__init__ doc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=simon dot marchi at ericsson dot com;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
I find the documentation of the gdb.Breakpoint constructor hard to read
and not very informative, especially since we have added the new
linespec parameters. There are multiple problems (some are subjective):
- It's not clear that you should use either the spec string or the
explicit arguments, not both.
- It's not clear what combination of parameters you can use.
- The big block of text describing the arguments is hard to read.
- Currently, it seems like the "spec" argument is mandatory, even though
it is not (if you use explicit linespec).
- The square bracket nesting
[arg1 [, arg2[, arg3]]]
makes it seems like if you specify arg3, you must specify arg1 and
arg2 (it's not the case here).
This patch tries to address these problems.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Split doc
of Breakpoint.__init__ in two, split text in multiple
paragraphs, don't nest parameter square brackets.
---
gdb/doc/python.texi | 61 +++++++++++++++++++++++++++++++++--------------------
1 file changed, 38 insertions(+), 23 deletions(-)
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 28a7a1a..47f4e07 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -4878,30 +4878,45 @@ represented as Python @code{Long} values.
Python code can manipulate breakpoints via the @code{gdb.Breakpoint}
class.
-@defun Breakpoint.__init__ (spec @r{[}, type @r{[}, wp_class @r{[}, internal @r{[}, temporary @r{]}, source @r{]}, function @r{]}, label @r{]}, line @r{]]]]]]]]})
-Create a new breakpoint according to @var{spec}, which is a string
-naming the location of the breakpoint, or an expression that defines a
-watchpoint. The contents can be any location recognized by the
-@code{break} command or, in the case of a watchpoint, by the
-@code{watch} command. Alternatively, create a new a explicit location
-breakpoint (@pxref{Explicit Locations}) according to the
-specifications contained in the key words @var{source},
-@var{function}, @var{label} and @var{line}. The optional @var{type}
-denotes the breakpoint to create from the types defined later in this
-chapter. This argument can be either @code{gdb.BP_BREAKPOINT} or
-@code{gdb.BP_WATCHPOINT}; it defaults to @code{gdb.BP_BREAKPOINT}.
-The optional @var{internal} argument allows the breakpoint to become
-invisible to the user. The breakpoint will neither be reported when
-created, nor will it be listed in the output from @code{info
-breakpoints} (but will be listed with the @code{maint info
-breakpoints} command). The optional @var{temporary} argument makes
-the breakpoint a temporary breakpoint. Temporary breakpoints are
-deleted after they have been hit. Any further access to the Python
-breakpoint after it has been hit will result in a runtime error (as
-that breakpoint has now been automatically deleted). The optional
-@var{wp_class} argument defines the class of watchpoint to create, if
-@var{type} is @code{gdb.BP_WATCHPOINT}. If a watchpoint class is not
+A breakpoint can be created using one of the two forms of the
+@code{gdb.Breakpoint} constructor. The first one accepts a @code{spec} string
+similar to what one would pass to the @code{break} command, and can be used to
+create both breakpoints and watchpoints. The second accepts separate Python
+arguments similar to @ref{Explicit Locations} and can only be used to create
+breakpoints.
+
+@defun Breakpoint.__init__ (spec @r{[}, type @r{][}, wp_class @r{][}, internal @r{][}, temporary @r{]})
+Create a new breakpoint according to @var{spec}, which is a string naming the
+location of a breakpoint, or an expression that defines a watchpoint. The
+contents can be any location recognized by the @code{break} command or, in the
+case of a watchpoint, by the @code{watch} command.
+
+The optional @var{type} argument denotes the breakpoint to create from the types
+defined later in this chapter. This argument can be either
+@code{gdb.BP_BREAKPOINT} or @code{gdb.BP_WATCHPOINT}; it defaults to
+@code{gdb.BP_BREAKPOINT}.
+
+The optional @var{wp_class} argument defines the class of watchpoint to create,
+if @var{type} is @code{gdb.BP_WATCHPOINT}. If a watchpoint class is not
provided, it is assumed to be a @code{gdb.WP_WRITE} class.
+
+The optional @var{internal} argument allows the breakpoint to become invisible
+to the user. The breakpoint will neither be reported when created, nor will it
+be listed in the output from @code{info breakpoints} (but will be listed with
+the @code{maint info breakpoints} command).
+
+The optional @var{temporary} argument makes the breakpoint a temporary
+breakpoint. Temporary breakpoints are deleted after they have been hit. Any
+further access to the Python breakpoint after it has been hit will result in a
+runtime error (as that breakpoint has now been automatically deleted).
+@end defun
+
+@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][}, label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][})
+Create a new explicit location breakpoint (@pxref{Explicit Locations})
+according to the specifications contained in the key words @var{source},
+@var{function}, @var{label} and @var{line}.
+
+@var{internal} and @var{temporary} have the same usage as explained previously.
@end defun
The available types are represented by constants defined in the @code{gdb}
--
2.7.4