On Wed, Jan 11, 2012 at 8:25 PM, Doug Evans <dje@google.com> wrote:
> On Jan 11, 2012 1:02 AM, "Kevin Pouget" <kevin.pouget@gmail.com> wrote:
>>
>> I'm not sure we can really move it away from the Python/Guile API,
>> because, AFAIU, this volatile aspect if purely internal. 'Normal'
>> users won't ever see it.
>>
>> > $ i b
>> > Num     Type           Disp Enb Address            What
>> > 1       breakpoint     keep y    <MULTIPLE>
>> >         1.1                         y     0x4562c0 in main at ../../../git/gdb/gdb/gdb.c:26 inf 2
>> >         1.2                         y     0x4562c0 in main at ../../../git/gdb/gdb/gdb.c:26 inf 1
>>
>> will remain the same all the time, but the objects (both in Python and
>> their GDB backends) in gdb.breakpoints()[0].locations() will be
>> deleted and re-created at various moments (cf. previous discussions).
>> So far, I couldn't really understand what's the rational behind that
>> ...
>>
>> [I'm not sure how well you know this part of GDB, please don't
>> hesitate to correct me if I'm wrong]
>
> Yikes, missed that.
> GDB internals are free to change at will, the python API is the exact opposite.
> This is the kind of API addition that gives me pause.
> Once it's in we're stuck.
>
> I once wrote a doc on managing GDB features/APIs, loosely based on
> what I could remember of the SystemV ABI.
> The ABI elements had three stages in their life, though I don't fully
> remember the details.
> IMO, IWBN to have something like it for our Python API.
> In particular, one could remove something, after a preset amount of
> time had passed since the announcement of its pending removal.
> And one could add new things without promising they'll be there forever.
> That scheme is old, and my memory is sketchy.
> My point is that today we don't have anything other than: "Once it's
> in we're stuck." [AFAICT]
>
> For the case at hand, IWBN to have some experience with whether this
> addition works well enough that we want to keep it.
> And it's not clear we can determine that without some real world use of it.

ping

I totally agree with Doug's discussion, but I'll let people with more
experience decide about the policy regarding Python API.


I've refreshed my patch against the current HEAD


Cordially,

Kevin

2012-01-27  Kevin Pouget  <kevin.pouget@st.com>

	Add bp_location to Python interface
	* Makefile.in (SUBDIR_PYTHON_OBS): Add py-bploc.o
	(SUBDIR_PYTHON_SRCS): Add python/py-bploc.c
	Add build rule for this file.
	* breakpoint.h (struct bploc_object): Forward declaration.
	(struct bp_location): Add py_bploc_obj.
	* breakpoint.c (free_bp_location): Call gdbpy_bplocation_free.
	* python/py-bploc.c: New file.
	* python/py-breakpoint.c (bppy_locations): New function.
	(breakpoint_object_methods): New method binding: locations().
	* python/python-internal.h (bploc_object): New typedef.
	(bplocation_to_bplocation_object): New prototype.
	(gdbpy_initialize_bplocation): Likewise.
	* python/python.c (gdbpy_bplocation_free): New empty stub.
	(_initialize_python): Call gdbpy_initialize_bplocation.
	* python/python.h (gdbpy_bplocation_free): New prototype.
	
doc/
	Add bp_location to Python interface
	* gdb.texinfo (Breakpoints In Python): Document
	gdb.Breakpoint.locations and gdb.BpLocation.


testsuite/
	Add bp_location to Python interface
	* gdb.python/py-breakpoint.exp: Test gdb.BpLocation.