Re: [python] Allow explicit locations in breakpoints.

[Simon Marchi <simon.marchi@ericsson.com>]

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