* [PATCH] python: Add qualified parameter to gdb.Breakpoint
@ 2017-12-07 22:34 Simon Marchi
2017-12-08 12:05 ` Pedro Alves
2017-12-08 14:15 ` Eli Zaretskii
0 siblings, 2 replies; 8+ messages in thread
From: Simon Marchi @ 2017-12-07 22:34 UTC (permalink / raw)
To: gdb-patches; +Cc: Simon Marchi
This patch adds the possibility to pass a qualified=True|False parameter
when creating a breakpoint in Python. It is equivalent to using
-qualified in a linespec. The parameter actually accepts any Python
value, and converts it to boolean using Python's standard rules for
that (https://docs.python.org/3/library/stdtypes.html#truth).
Unlike the -source/-line/-function/-label parameters, it is possible to
use -qualified with a "normal" (non-explicit) linespec. Therefore, it
is possible (unlike these other parameters) to use this new parameter
along with the spec parameter.
I updated the py-breakpoint.exp test. To be able to test multiple
locations using a namespace, I had to switch the test case to compile as
C++. If we really wanted to, we could run it as both C and C++, but
omit the C++-specific parts when running it as C.
gdb/ChangeLog:
* location.h (string_to_event_location): Add match_type
parameter.
* location.c (string_to_event_location): Likewise.
* python/py-breakpoint.c (bppy_init): Handle qualified
parameter.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Document
qualified parameter to gdb.Breakpoint.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
* gdb.python/py-breakpoint.exp: Compile the test case as c++,
call test_bkpt_qualified.
(test_bkpt_qualified): New proc.
---
gdb/doc/python.texi | 12 +++--
gdb/location.c | 4 +-
gdb/location.h | 11 +++--
gdb/python/py-breakpoint.c | 16 +++++--
gdb/testsuite/gdb.python/py-breakpoint.c | 8 ++++
gdb/testsuite/gdb.python/py-breakpoint.exp | 76 +++++++++++++++++++++++++++++-
6 files changed, 113 insertions(+), 14 deletions(-)
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi
index 47f4e07..78280d0 100644
--- a/gdb/doc/python.texi
+++ b/gdb/doc/python.texi
@@ -4885,7 +4885,7 @@ 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{]})
+@defun Breakpoint.__init__ (spec @r{[}, type @r{][}, wp_class @r{][}, internal @r{][}, temporary @r{][}, qualified @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
@@ -4909,14 +4909,20 @@ 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{qualified} argument is a boolean that allows restricting the
+breakpoint to free-functions. It is equivalent to @code{break}'s
+@code{-qualified} flag (@pxref{Linespec Locations}).
+
@end defun
-@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][}, label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][})
+@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][}, label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][}, qualified @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.
+@var{internal}, @var{temporary} and @var{qualified} have the same usage as
+explained previously.
@end defun
The available types are represented by constants defined in the @code{gdb}
diff --git a/gdb/location.c b/gdb/location.c
index 6752462..0f79764 100644
--- a/gdb/location.c
+++ b/gdb/location.c
@@ -915,10 +915,10 @@ string_to_event_location_basic (const char **stringp,
event_location_up
string_to_event_location (const char **stringp,
- const struct language_defn *language)
+ const struct language_defn *language,
+ symbol_name_match_type match_type)
{
const char *arg, *orig;
- symbol_name_match_type match_type = symbol_name_match_type::WILD;
/* Try an explicit location. */
orig = arg = *stringp;
diff --git a/gdb/location.h b/gdb/location.h
index fcfa8fb..d5d879d 100644
--- a/gdb/location.h
+++ b/gdb/location.h
@@ -220,11 +220,14 @@ extern event_location_up
This function is intended to be used by CLI commands and will parse
explicit locations in a CLI-centric way. Other interfaces should use
string_to_event_location_basic if they want to maintain support for
- legacy specifications of probe, address, and linespec locations. */
+ legacy specifications of probe, address, and linespec locations.
-extern event_location_up
- string_to_event_location (const char **argp,
- const struct language_defn *langauge);
+ MATCH_TYPE should be either WILD or FULL. If -q/--qualified is specified
+ in the input string, it will take precedence over this parameter. */
+
+extern event_location_up string_to_event_location
+ (const char **argp, const struct language_defn *langauge,
+ symbol_name_match_type match_type = symbol_name_match_type::WILD);
/* Like string_to_event_location, but does not attempt to parse
explicit locations. MATCH_TYPE indicates how function names should
diff --git a/gdb/python/py-breakpoint.c b/gdb/python/py-breakpoint.c
index f865317..5239713 100644
--- a/gdb/python/py-breakpoint.c
+++ b/gdb/python/py-breakpoint.c
@@ -694,7 +694,7 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs)
{
static const char *keywords[] = { "spec", "type", "wp_class", "internal",
"temporary","source", "function",
- "label", "line", NULL };
+ "label", "line", "qualified", NULL };
const char *spec = NULL;
enum bptype type = bp_breakpoint;
int access_type = hw_write;
@@ -707,12 +707,14 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs)
char *label = NULL;
char *source = NULL;
char *function = NULL;
+ int qualified = 0;
- if (!gdb_PyArg_ParseTupleAndKeywords (args, kwargs, "|siiOOsssO", keywords,
+ if (!gdb_PyArg_ParseTupleAndKeywords (args, kwargs, "|siiOOsssOp", keywords,
&spec, &type, &access_type,
&internal,
&temporary, &source,
- &function, &label, &lineobj))
+ &function, &label, &lineobj,
+ &qualified))
return -1;
@@ -759,6 +761,9 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs)
case bp_breakpoint:
{
event_location_up location;
+ symbol_name_match_type func_name_match_type
+ = qualified ? symbol_name_match_type::FULL
+ : symbol_name_match_type::WILD;
if (spec != NULL)
{
@@ -767,7 +772,8 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs)
const char *copy = copy_holder.get ();
location = string_to_event_location (©,
- current_language);
+ current_language,
+ func_name_match_type);
}
else
{
@@ -782,6 +788,8 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs)
explicit_loc.line_offset =
linespec_parse_line_offset (line.get ());
+ explicit_loc.func_name_match_type = func_name_match_type;
+
location = new_explicit_location (&explicit_loc);
}
diff --git a/gdb/testsuite/gdb.python/py-breakpoint.c b/gdb/testsuite/gdb.python/py-breakpoint.c
index 562cab3..c9f124c 100644
--- a/gdb/testsuite/gdb.python/py-breakpoint.c
+++ b/gdb/testsuite/gdb.python/py-breakpoint.c
@@ -17,6 +17,14 @@
int result = 0;
+namespace foo_ns
+{
+ int multiply (int i)
+ {
+ return i * i;
+ }
+}
+
int multiply (int i)
{
return i * i;
diff --git a/gdb/testsuite/gdb.python/py-breakpoint.exp b/gdb/testsuite/gdb.python/py-breakpoint.exp
index e89b9b8..7b4cfaa 100644
--- a/gdb/testsuite/gdb.python/py-breakpoint.exp
+++ b/gdb/testsuite/gdb.python/py-breakpoint.exp
@@ -20,7 +20,9 @@ load_lib gdb-python.exp
standard_testfile
-if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
+set options {debug c++}
+
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} ${options}] } {
return -1
}
@@ -610,6 +612,77 @@ proc test_bkpt_explicit_loc {} {
}
}
+proc_with_prefix test_bkpt_qualified {} {
+ global decimal hex testfile
+
+ # Start with a fresh gdb.
+ clean_restart ${testfile}
+
+ set one_location_re "Breakpoint $decimal at $hex:.*line $decimal."
+ set two_location_re "Breakpoint $decimal at $hex:.*2 locations."
+
+ if ![runto_main] then {
+ fail "cannot run to main."
+ return 0
+ }
+
+ # Test the default value of "qualified".
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(\"multiply\")" \
+ $two_location_re \
+ "qualified implicitly false"
+
+ # Test qualified=False.
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(\"multiply\", qualified=False)" \
+ $two_location_re \
+ "qualified false"
+
+ # Test qualified=True.
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(\"multiply\", qualified=True)" \
+ $one_location_re \
+ "qualified true"
+
+ # Test qualified=True with an explicit function.
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(function=\"multiply\", qualified=True)" \
+ $one_location_re \
+ "qualified true and explicit"
+
+ # Test qualified=False with an explicit function.
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(function=\"multiply\", qualified=False)" \
+ $two_location_re \
+ "qualified false and explicit"
+
+ # Test -q in the spec string.
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(\"-q multiply\")" \
+ $one_location_re \
+ "-q in spec string"
+
+ # Test -q in the spec string with explicit location.
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(\"-q -function multiply\")" \
+ $one_location_re \
+ "-q in spec string with explicit location"
+
+ # Test -q in the spec string and qualified=False (-q should win).
+ delete_breakpoints
+ gdb_test \
+ "python gdb.Breakpoint(\"-q multiply\", qualified=False)" \
+ $one_location_re \
+ "-q in spec string and qualified false"
+}
+
test_bkpt_basic
test_bkpt_deletion
test_bkpt_cond_and_cmds
@@ -622,3 +695,4 @@ test_bkpt_address
test_bkpt_pending
test_bkpt_events
test_bkpt_explicit_loc
+test_bkpt_qualified
--
2.7.4
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-07 22:34 [PATCH] python: Add qualified parameter to gdb.Breakpoint Simon Marchi
@ 2017-12-08 12:05 ` Pedro Alves
2017-12-08 18:42 ` Simon Marchi
2017-12-08 14:15 ` Eli Zaretskii
1 sibling, 1 reply; 8+ messages in thread
From: Pedro Alves @ 2017-12-08 12:05 UTC (permalink / raw)
To: Simon Marchi, gdb-patches
That was fast. :-) Thanks!
See comments about the docs below.
The code looks fine to me, except a formatting nit.
> --- a/gdb/doc/python.texi
> +++ b/gdb/doc/python.texi
> @@ -4885,7 +4885,7 @@ 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{]})
> +@defun Breakpoint.__init__ (spec @r{[}, type @r{][}, wp_class @r{][}, internal @r{][}, temporary @r{][}, qualified @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
> @@ -4909,14 +4909,20 @@ 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{qualified} argument is a boolean that allows restricting the
> +breakpoint to free-functions.
"free-functions" is incorrect. With:
struct A { void func (); } // #1
namespace B { struct A { void func (); } } // #2
"b -q A::func()" only matches #1 while
"b A::func()" matches both #1 and #2.
and A::func() above is not a free function.
Here's what we say for -qualified in the explicit locations part of the
manual:
~~~
@item -qualified
This flag makes @value{GDBN} interpret a function name specified with
@kbd{-function} as a complete fully-qualified name.
For example, assuming a C@t{++} program with symbols named
@code{A::B::func} and @code{B::func}, the @w{@kbd{break -qualified
-function B::func}} command sets a breakpoint on @code{B::func}, only.
(Note: the @kbd{-qualified} option can precede a linespec as well
(@pxref{Linespec Locations}), so the particular example above could be
simplified as @w{@kbd{break -qualified B::func}}.)
~~~
There's similar text in the linespecs part of the manual and also
in "help break". See:
$ git show a20714ff39f6 -- doc/gdb.texinfo NEWS break.c
So we either need to clarify that in the Python bits too,
or some do some xref'ing.
It is equivalent to @code{break}'s
> +@code{-qualified} flag (@pxref{Linespec Locations}).
> +
> @end defun
>
> -@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][}, label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][})
> +@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][}, label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][}, qualified @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}.
Should @var{qualified} be added to this list too?
(BTW, noticed a typo in this paragraph:
"create a new a explicit location"
the second "a" is spurious.)
>
> -@var{internal} and @var{temporary} have the same usage as explained previously.
> +@var{internal}, @var{temporary} and @var{qualified} have the same usage as
> +explained previously.
> @end defun
>
> The available types are represented by constants defined in the @code{gdb}
> @@ -759,6 +761,9 @@ bppy_init (PyObject *self, PyObject *args, PyObject *kwargs)
> case bp_breakpoint:
> {
> event_location_up location;
> + symbol_name_match_type func_name_match_type
> + = qualified ? symbol_name_match_type::FULL
> + : symbol_name_match_type::WILD;
Should wrap the multi-line expression in ()s:
symbol_name_match_type func_name_match_type
= (qualified ? symbol_name_match_type::FULL
: symbol_name_match_type::WILD);
Though I prefer breaking ternary operators like this:
symbol_name_match_type func_name_match_type
= (qualified
? symbol_name_match_type::FULL
: symbol_name_match_type::WILD);
because it makes it look more obviously like
if COND
THEN
ELSE
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-07 22:34 [PATCH] python: Add qualified parameter to gdb.Breakpoint Simon Marchi
2017-12-08 12:05 ` Pedro Alves
@ 2017-12-08 14:15 ` Eli Zaretskii
2017-12-08 18:27 ` Simon Marchi
1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2017-12-08 14:15 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> From: Simon Marchi <simon.marchi@ericsson.com>
> CC: Simon Marchi <simon.marchi@ericsson.com>
> Date: Thu, 7 Dec 2017 17:33:33 -0500
>
> This patch adds the possibility to pass a qualified=True|False parameter
> when creating a breakpoint in Python. It is equivalent to using
> -qualified in a linespec. The parameter actually accepts any Python
> value, and converts it to boolean using Python's standard rules for
> that (https://docs.python.org/3/library/stdtypes.html#truth).
>
> Unlike the -source/-line/-function/-label parameters, it is possible to
> use -qualified with a "normal" (non-explicit) linespec. Therefore, it
> is possible (unlike these other parameters) to use this new parameter
> along with the spec parameter.
>
> I updated the py-breakpoint.exp test. To be able to test multiple
> locations using a namespace, I had to switch the test case to compile as
> C++. If we really wanted to, we could run it as both C and C++, but
> omit the C++-specific parts when running it as C.
>
> gdb/ChangeLog:
>
> * location.h (string_to_event_location): Add match_type
> parameter.
> * location.c (string_to_event_location): Likewise.
> * python/py-breakpoint.c (bppy_init): Handle qualified
> parameter.
>
> gdb/doc/ChangeLog:
>
> * python.texi (Manipulating breakpoints using Python): Document
> qualified parameter to gdb.Breakpoint.
>
> gdb/testsuite/ChangeLog:
>
> * gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
> * gdb.python/py-breakpoint.exp: Compile the test case as c++,
> call test_bkpt_qualified.
> (test_bkpt_qualified): New proc.
OK for the documentation part. (Do we need a NEWS entry?)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-08 14:15 ` Eli Zaretskii
@ 2017-12-08 18:27 ` Simon Marchi
2017-12-08 19:47 ` Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Simon Marchi @ 2017-12-08 18:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb-patches
On 2017-12-08 09:15 AM, Eli Zaretskii wrote:
>> From: Simon Marchi <simon.marchi@ericsson.com>
>> CC: Simon Marchi <simon.marchi@ericsson.com>
>> Date: Thu, 7 Dec 2017 17:33:33 -0500
>>
>> This patch adds the possibility to pass a qualified=True|False parameter
>> when creating a breakpoint in Python. It is equivalent to using
>> -qualified in a linespec. The parameter actually accepts any Python
>> value, and converts it to boolean using Python's standard rules for
>> that (https://docs.python.org/3/library/stdtypes.html#truth).
>>
>> Unlike the -source/-line/-function/-label parameters, it is possible to
>> use -qualified with a "normal" (non-explicit) linespec. Therefore, it
>> is possible (unlike these other parameters) to use this new parameter
>> along with the spec parameter.
>>
>> I updated the py-breakpoint.exp test. To be able to test multiple
>> locations using a namespace, I had to switch the test case to compile as
>> C++. If we really wanted to, we could run it as both C and C++, but
>> omit the C++-specific parts when running it as C.
>>
>> gdb/ChangeLog:
>>
>> * location.h (string_to_event_location): Add match_type
>> parameter.
>> * location.c (string_to_event_location): Likewise.
>> * python/py-breakpoint.c (bppy_init): Handle qualified
>> parameter.
>>
>> gdb/doc/ChangeLog:
>>
>> * python.texi (Manipulating breakpoints using Python): Document
>> qualified parameter to gdb.Breakpoint.
>>
>> gdb/testsuite/ChangeLog:
>>
>> * gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
>> * gdb.python/py-breakpoint.exp: Compile the test case as c++,
>> call test_bkpt_qualified.
>> (test_bkpt_qualified): New proc.
>
> OK for the documentation part. (Do we need a NEWS entry?)
A NEWS entry would be good. I think we can complement the existing one about
-qualified instead of making a new one. What about this?
diff --git a/gdb/NEWS b/gdb/NEWS
index c6fe297..bd5ae36 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -81,7 +81,9 @@
GDB interpret the specified function name as a complete
fully-qualified name instead. For example, using the same C++
program, the "break -q B::func" command sets a breakpoint on
- "B::func", only.
+ "B::func", only. A parameter has been added to the Python
+ gdb.Breakpoint constructor to achieve the same result when creating
+ a breakpoint from Python.
* Breakpoints on functions marked with C++ ABI tags
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-08 12:05 ` Pedro Alves
@ 2017-12-08 18:42 ` Simon Marchi
2017-12-13 13:17 ` Pedro Alves
0 siblings, 1 reply; 8+ messages in thread
From: Simon Marchi @ 2017-12-08 18:42 UTC (permalink / raw)
To: Pedro Alves; +Cc: Simon Marchi, gdb-patches
On 2017-12-08 07:05, Pedro Alves wrote:
> That was fast. :-) Thanks!
>
> See comments about the docs below.
>
> The code looks fine to me, except a formatting nit.
>
>> --- a/gdb/doc/python.texi
>> +++ b/gdb/doc/python.texi
>> @@ -4885,7 +4885,7 @@ 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{]})
>> +@defun Breakpoint.__init__ (spec @r{[}, type @r{][}, wp_class @r{][},
>> internal @r{][}, temporary @r{][}, qualified @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
>> @@ -4909,14 +4909,20 @@ 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{qualified} argument is a boolean that allows
>> restricting the
>> +breakpoint to free-functions.
>
> "free-functions" is incorrect. With:
>
> struct A { void func (); } // #1
> namespace B { struct A { void func (); } } // #2
>
> "b -q A::func()" only matches #1 while
> "b A::func()" matches both #1 and #2.
>
> and A::func() above is not a free function.
>
> Here's what we say for -qualified in the explicit locations part of the
> manual:
>
> ~~~
> @item -qualified
>
> This flag makes @value{GDBN} interpret a function name specified with
> @kbd{-function} as a complete fully-qualified name.
>
> For example, assuming a C@t{++} program with symbols named
> @code{A::B::func} and @code{B::func}, the @w{@kbd{break -qualified
> -function B::func}} command sets a breakpoint on @code{B::func}, only.
>
> (Note: the @kbd{-qualified} option can precede a linespec as well
> (@pxref{Linespec Locations}), so the particular example above could be
> simplified as @w{@kbd{break -qualified B::func}}.)
> ~~~
>
> There's similar text in the linespecs part of the manual and also
> in "help break". See:
> $ git show a20714ff39f6 -- doc/gdb.texinfo NEWS break.c
>
> So we either need to clarify that in the Python bits too,
> or some do some xref'ing.
Agreed, I didn't like that wording either. I had only found the
Linespec Locations page, which doesn't specifically say "fully-qualified
name", but mentions free-function (though it's in an example, not a
formal definition). How is this?
The optional @var{qualified} argument is a boolean that allows
interpreting
the function passed in @code{spec} as a fully-qualified name. It is
equivalent
to @code{break}'s @code{-qualified} flag (@pxref{Linespec Locations} and
@ref{Explicit Locations}).
> It is equivalent to @code{break}'s
>> +@code{-qualified} flag (@pxref{Linespec Locations}).
>> +
>> @end defun
>>
>> -@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][},
>> label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][})
>> +@defun Breakpoint.__init__ (@r{[} source @r{][}, function @r{][},
>> label @r{][}, line @r{]}, @r{][} internal @r{][}, temporary @r{][},
>> qualified @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}.
>
> Should @var{qualified} be added to this list too?
It is mentioned in the paragraph below.
> (BTW, noticed a typo in this paragraph:
>
> "create a new a explicit location"
>
> the second "a" is spurious.)
That text changed based on Eli's comments, but thanks anyway.
>>
>> -@var{internal} and @var{temporary} have the same usage as explained
>> previously.
>> +@var{internal}, @var{temporary} and @var{qualified} have the same
>> usage as
>> +explained previously.
>> @end defun
>>
>> The available types are represented by constants defined in the
>> @code{gdb}
>
>> @@ -759,6 +761,9 @@ bppy_init (PyObject *self, PyObject *args,
>> PyObject *kwargs)
>> case bp_breakpoint:
>> {
>> event_location_up location;
>> + symbol_name_match_type func_name_match_type
>> + = qualified ? symbol_name_match_type::FULL
>> + : symbol_name_match_type::WILD;
>
> Should wrap the multi-line expression in ()s:
>
> symbol_name_match_type func_name_match_type
> = (qualified ? symbol_name_match_type::FULL
> : symbol_name_match_type::WILD);
>
> Though I prefer breaking ternary operators like this:
>
> symbol_name_match_type func_name_match_type
> = (qualified
> ? symbol_name_match_type::FULL
> : symbol_name_match_type::WILD);
>
> because it makes it look more obviously like
>
> if COND
> THEN
> ELSE
Done.
Thanks,
Simon
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-08 18:27 ` Simon Marchi
@ 2017-12-08 19:47 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2017-12-08 19:47 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> From: Simon Marchi <simon.marchi@ericsson.com>
> Date: Fri, 8 Dec 2017 13:26:48 -0500
>
> > OK for the documentation part. (Do we need a NEWS entry?)
>
> A NEWS entry would be good. I think we can complement the existing one about
> -qualified instead of making a new one. What about this?
>
> diff --git a/gdb/NEWS b/gdb/NEWS
> index c6fe297..bd5ae36 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -81,7 +81,9 @@
> GDB interpret the specified function name as a complete
> fully-qualified name instead. For example, using the same C++
> program, the "break -q B::func" command sets a breakpoint on
> - "B::func", only.
> + "B::func", only. A parameter has been added to the Python
> + gdb.Breakpoint constructor to achieve the same result when creating
> + a breakpoint from Python.
>
> * Breakpoints on functions marked with C++ ABI tags
Fine with me, thanks.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-08 18:42 ` Simon Marchi
@ 2017-12-13 13:17 ` Pedro Alves
2017-12-13 16:45 ` Simon Marchi
0 siblings, 1 reply; 8+ messages in thread
From: Pedro Alves @ 2017-12-13 13:17 UTC (permalink / raw)
To: Simon Marchi; +Cc: Simon Marchi, gdb-patches
On 12/08/2017 06:42 PM, Simon Marchi wrote:
>> So we either need to clarify that in the Python bits too,
>> or some do some xref'ing.
>
> Agreed, I didn't like that wording either. I had only found the
> Linespec Locations page, which doesn't specifically say "fully-qualified
> name", but mentions free-function (though it's in an example, not a
> formal definition). How is this?
>
> The optional @var{qualified} argument is a boolean that allows interpreting
> the function passed in @code{spec} as a fully-qualified name. It is
> equivalent
> to @code{break}'s @code{-qualified} flag (@pxref{Linespec Locations} and
> @ref{Explicit Locations}).
Thanks, that looks fine.
(I thought I had replied earlier, but looks like I dreamt it.)
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] python: Add qualified parameter to gdb.Breakpoint
2017-12-13 13:17 ` Pedro Alves
@ 2017-12-13 16:45 ` Simon Marchi
0 siblings, 0 replies; 8+ messages in thread
From: Simon Marchi @ 2017-12-13 16:45 UTC (permalink / raw)
To: Pedro Alves; +Cc: Simon Marchi, gdb-patches
On 2017-12-13 08:17, Pedro Alves wrote:
> On 12/08/2017 06:42 PM, Simon Marchi wrote:
>
>>> So we either need to clarify that in the Python bits too,
>>> or some do some xref'ing.
>>
>> Agreed, I didn't like that wording either. I had only found the
>> Linespec Locations page, which doesn't specifically say
>> "fully-qualified
>> name", but mentions free-function (though it's in an example, not a
>> formal definition). How is this?
>>
>> The optional @var{qualified} argument is a boolean that allows
>> interpreting
>> the function passed in @code{spec} as a fully-qualified name. It is
>> equivalent
>> to @code{break}'s @code{-qualified} flag (@pxref{Linespec Locations}
>> and
>> @ref{Explicit Locations}).
>
> Thanks, that looks fine.
>
> (I thought I had replied earlier, but looks like I dreamt it.)
>
> Thanks,
> Pedro Alves
Thanks, it is now pushed.
Simon
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-12-13 16:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-07 22:34 [PATCH] python: Add qualified parameter to gdb.Breakpoint Simon Marchi
2017-12-08 12:05 ` Pedro Alves
2017-12-08 18:42 ` Simon Marchi
2017-12-13 13:17 ` Pedro Alves
2017-12-13 16:45 ` Simon Marchi
2017-12-08 14:15 ` Eli Zaretskii
2017-12-08 18:27 ` Simon Marchi
2017-12-08 19:47 ` Eli Zaretskii
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).