Re: [python] Allow explicit locations in breakpoints.

[Phil Muldoon <pmuldoon@redhat.com>]

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?

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.

Cheers

Phil