Re: Python API plans

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> There are two areas I would like to see improved beyond the initial
Phil> patch.  I have no opinion whether these can be incrementally improved
Phil> after submission, or if we should hack on them first.

These look good.  I think it is a good idea for the first commit of a
few feature to be as "API-complete" as we can make it: that is, we
should try to reduce the number of future changes to which a user must
adapt.  E.g., changing the return type of a method is hard to adapt to,
but adding a new method to a class is easy to adapt to.  In this
particular case, I think it is best to try to make the events as
expressive as possible first; but the details of how events are
implemented (Python or C) are not important provided they are
future-proof.

Phil> I agree about the eager loading.  It might amount to nothing at all.
Phil> If it does turn out to be expensive, what about having commands
Phil> register themselves against a global Python list? This would be
Phil> similar to how pretty-printers work.  We could defer loading until the
Phil> command is needed, but still (with some alteration to the completion
Phil> code) allow the user to see the command-list in 'help 'and make the
Phil> commands available for tab-completion?

I think there is a simpler way that we could try first:

    http://sourceware.org/ml/gdb-patches/2010-07/msg00201.html

This wouldn't require any changes to the gdb core.

Tom> * Sometimes it would be nice to write a command with the same name as
Tom> an existing command, but then delegate to the existing command (say,
Tom> via a super call).

Phil> Do you mean purely Python commands overriding other Python commands, or
Phil> in-built commands as well?
 
I meant built-in commands, but being generic would not be bad.

Phil> I'm not sure if you can run arbitrary Python code in a condition
Phil> though (i.e., .condition("python if somePythonFunction() ==
Phil> True").

Yeah, you can via a convenience function.  That is pretty ugly though.

Phil> Ideally I'd like the Python API to be fully aware of the state of the
Phil> inferior. On the flip-side I'd also to be able to control the
Phil> inferior in a more atomic way than issuing gdb.execute("step")
Phil> commands and guessing if the inferior did as expected.

The dreaded MI wrappers would achieve this ;-)

I'm mildly concerned about writing a bunch of wrappers for these
commands that work either synchronously or asynchronously, depending on
the non-stop setting.  It seems like it would be preferable to make them
always async, with some kind of completion hook.  But, I think that may
require a big gdb change, like always enabling non-stop or something
along those lines.

So, I think we should defer explicit support for step/next/etc until we
have a bit more clarity about long term goals here.  (I don't really
consider the MI wrapper project as "explicit" -- since that is more
like, do one change and get a bunch of stuff "for free", even if some of
what you get is useless or doesn't really make sense.)

Phil> * Python breakpoints to support 'catch' breakpoints (especially the
Phil>   system-call variety).

Sounds good.

Phil> * Make it so that tab completion knows about Python API
Phil>   completions. So (gdb) gdb.<TAB> would list all of the available
Phil>   Python bits associated with the GDB module.

Make this lower priority.  It might be nice to have but I think basic
functionality is more important.

Phil> * Python representation of a target.

I think the note on the wiki was about letting people write new targets
in Python.  This might be interesting but I think it is a very low
priority.

If there are parts of the target or gdbarch that are needed for generic
scripting stuff, then we should export those via some read-only
interface.

Phil> * Allow Python scripts to control start-up of GDB so it allows the
Phil>   equivalent of gcore like commands.

I pushed this kind of scripting/tracing idea for a while.  And, I do
still like it.  But I also think that, for us, systemtap fills the
non-interactive tracing role quite well.

So, I think we should focus more on gdb's interactive functionality.

I'd like to do some deeper systemtap integration with gdb, too, but that
isn't on this list since it isn't related to Python.

Tom