This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [python] Allow explicit locations in breakpoints.
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>, Keith Seitz <keiths at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 16 Oct 2017 17:25:59 -0400
- Subject: Re: [python] Allow explicit locations in breakpoints.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=simon dot marchi at ericsson dot com;
- References: <04ccc2c4-7827-eedc-d8db-a83a0167acb6@redhat.com> <d1899991-db61-b663-7601-86dfa38449a2@redhat.com> <58311250-9ab1-39d1-99b6-07478bc8c2ab@redhat.com> <4768c7ad-cc3d-5702-fa93-40e9760d4ee8@ericsson.com> <c6934b14-6025-5638-6922-2cc3d1ef3a9c@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 2017-10-16 04:24 PM, Phil Muldoon wrote:
> On 16/10/17 19:23, Simon Marchi wrote:
>> On 2017-08-23 02:30 PM, Phil Muldoon wrote:
>>> On 23/08/17 18:51, Keith Seitz wrote:
>>>> On 08/23/2017 06:58 AM, Phil Muldoon wrote:
>
>> I think for Python it would make sense to support the two paradigms. If you
>> are writing a Python command that ends up installing a breakpoint, it would
>> be nice if you could directly pass what you received to the gdb.Breakpoint
>> constructor and have it parse it (including explicit locations). For example,
>>
>> (gdb) special-break -file foo.c -line 17
>>
>> But it would also be nice to have a keywords based API, for when the line/file/function
>> information is already split. It would avoid having to build an explicit linespec
>> string just to have GDB parse it after.
>>
>> In terms of API, I think the "spec" argument could be mutually exclusive with
>> the function/file/line/etc keywork arguments, which would be added. An error
>> would be thrown if you try to use both ways at the same time.
>>
>> About the line="+3" issue, because this is Python, the line keyword could
>> probably accept integers and strings. And if it's a string, there could
>> be some validation on the format.
>>
>
> Simon,
>
> Thanks for the review. For the record I have no objection to the
> keywords API in addition to the spec line.
>
> But I'm not sure what you mean about the line argument taking an
> integer or a string. So line is a problem; it can be:
>
> - line=3 (at line three in the source code)
> - line=+3 (plus three lines from current source location)
> - line=-3 (minus three lines from current source location)
>
> I'm not sure how I could write a ParseTupleAndKeyword to accept that
> in any form other than a string? The -3 will be a minus three, the +3
> will just be a 3, and the =3 will be a 3 too. The problem is the
> relative "+" information gets lost. Did you have something else in
> mind? I guess I could use the O& in the format string to invoke a
> converter function? I'm not quite sure what you intend though?
I think we could support all of these:
line=3
line='3'
line='+3'
line='-3'
I was thinking about using the O modifier, to get a plain PyObject*, and
then check what type it really is (int or string). But I didn't know
about O&, which looks like a good fit. The converter function could
make use of linespec_parse_line_offset if the passed argument is a string.
> For now, though, I'll add the keywords (as strings) in. This really
> prompts me to think we should rewrite the gdb.Breakpoint constructor
> to not use create_breakpoint and be more MI-like in the creation of
> breakpoints.
I'm not sure what you mean, MI uses create_breakpoint in mi_cmd_break_insert_1.
Simon