Re: more OO, use breakpoints_ops for all kinds of breakpoints (Re: [patch] [python] Expose some breakpoint operations to Python)

[Phil Muldoon <pmuldoon at redhat dot com>]

Pedro Alves <pedro@codesourcery.com> writes:

>> I'd like to finish that conversion soon.

Thanks for the patch!

> I did a bit more work on this.  Watchpoints were already using
> breakpoint_ops.  I added a bkpt_breakpoint_ops for all software/hardware
> breakpoints, and a tracepoint_ops for all kinds of tracepoints,
> and moved the default actions to the appropriate places.  There
> were places where I could cleanup a bit further, but I figured
> I'd better do those as follow ups.  I think these 4 major
> kinds of "breakpoints" is already a good start.  Further
> refinement could split internal / momentary breakpoints
> into its own ops, for example.

I've not converted my Python patch to use this yet, but it looks like it
would be fairly simple.  FWIW, I think this is great.

> I left behind the print_one method, as that seems will
> require something else, or some disentanglement.

I don't have the file open at this moment, but if I remember correctly
this is the callback that can fail with breakpoints that have multiple
locations?  If we could convert that assert() to an error() I could
catch it and deal with it.  If I remember correctly, asserts do not
propagate through the exception framework as normal GDB errors, so we
would have to do something here to let the Python code manage this
error?  Generally, as a side point, asserts are somewhat the bane of my
life especially if they do not indicate fatal GDB situations.

> The current insert/remove abstration is at raw location level.
> We can't use it as is to split insert_bp_location.  We may need
> to rename the current methods to e.g., insert_raw_location (or
> move them to the bp_location vtable), and add new breakpoint_ops
> methods that call the raw methods, and, handle the different
> warnings and insert-failed->revert paths as appropriate per
> breakpoint type.

Sounds good to me.  I was thinking on this from the Python side, when
(if) we finally propagate this functionality to the API.  Right now I do
not see how we could abstract these functions enough (into a more
discrete GDB-side API) to allow the Python user to use them safely.  It seems
to require an awful lot of internals from GDB to make accurate decision,
and I am a little uncomfortable with allowing this level of
introspection from the Python side.  On could argue this allows for a
deeper, more powerful API, but there is a risk that internals could
change that would force a Python API break.  Anyway, I ramble on ... I
think your logic is sound with the baser more raw callbacks.

>
> This has no regressions for me.  It misses some comments and
> cosmetics here and there, and a ChangeLog entry.  I'll try to
> get back to this soon, but I've got other fish to fry at
> the moment.

Thanks for doing this.  I do not see any regressions either.

Cheers,

Phil

-- 
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)