Re: [PATCH] Add bp_location to Python interface

[Kevin Pouget <kevin.pouget@gmail.com>]

On Thu, Dec 8, 2011 at 2:08 PM, Phil Muldoon <pmuldoon@redhat.com> wrote:
> Kevin Pouget <kevin.pouget@gmail.com> writes:
>
>> Hello,
>>
>> I would like to discuss this patch which introduces a new Python class
>> gdb.BpLocation, mapped from breakpoint.h::struct bp_location.
>
> Thanks.
>
>> I noticed that the Python interface doesn't offer so many details
>> about breakpoint location, just gdb.Breakpoint.location, the string
>> used to set the breakpoint (its linespec?)
>
> Because we use gdb.Breakpoints for watchpoints as well, it also
> represents the expression used to set the watchpoint.

I didn't consider watchpoints at all during this work, I'll add it to
the testsuite to ensure it's handling correctly

>> So this new class, which is currently strictly read-only and not
>> instantiatable, exports the address and inferior in which the
>> breakpoint was set (and an enabled flag, and a link to its owner
>> breakpoint).
>
> I think it should only ever be read-only.

yes, certainly. My original idea was to allow Python to add new
BpLocations, but that's the way GDB was designed to work! Anyway, I
think that Tom's patch has solved the problem by correctly spreading
breakpoints to new inferiors.

>> BpLocation object are available through the gdb.Breakpoint.locations method.
>
> If a user expected a string for a location, delivering an object here
> would break API?

I'm not sure to get you right, but I didn't change the original API
behavior. There are now two ... method/atribute, `Breakpoint.location`
which returns a string (bp->addr_string) and
`Breakpoint.location_s_(self)' which returns a tuple of gdb.BpLocation
objects.

The name "locations" might be confusing, but I've got no other wording
for it so far, and I think it's too late to rename "location" to
"spec",

(there is a missing Py_DECREF(list) in bppy_locations, I'll fix it for
the next patch)

>> I think that this class would also help Python users to better
>> control/understand where their breakpoints are set with Tom's recent
>> changes about ambiguous linespec
>
> Yes I think so too.

another advantage is to allow the detection of pending breakpoints:

if len(bp.locations()) == 0, the breakpoint is pending

(and we'll have to find a way to find a way to keep GDB quite when a
pending breakpoint is created (I'll post a bug report for that):

> (gdb) py gdb.Breakpoint("pending")
> Function "pending" not defined.
> Breakpoint 2 (pending) pending.


Cordially,

Kevin