Python API plans

[Tom Tromey <tromey at redhat dot com>]

Phil asked me to write up a list of the various Python projects that I
think we should pursue in gdb.  So, here it is; I welcome feedback,
additions, etc.  Don't expect many details here, it is really just the
result of making notes whenever I missed something over the last couple
of years.

* Rebase and polish Oguz's inferior event work from the 2009 SoC.  I
  think Oguz has started looking into this again.  This functionality
  blocks a number of interesting Python uses; I think the event registry
  work is needed for some other (smaller) projects too.

* Fix all open bugs.

* Polish some of the existing commands and functions from the
  archer-tromey-python branch.  Sub-tasks:

  * Finish the command-loading code.  Time eager loading to see how
    expensive it is; if too expensive, write some lazy-loading
    wrappers.  (We definitely do not want the "require" command from the
    branch.)

  * (See below for info on frame wrapper, new-backtrace, etc.)

* Write Python wrappers for all MI commands, see:

    http://sourceware.org/bugzilla/show_bug.cgi?id=11688

  This is an easy (-ish) way to provide a simple API to most of the
  relevant parts of GDB.

* Generic command improvements.

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

  * Likewise it would be nice if you could easily uninstall an
    overriding command.

  These considerations are why "new-backtrace" isn't just called
  "backtrace" -- if it has a bug the user is just stuck with it.  Maybe
  just a "rename" facility is enough (or maybe just the existing
  alias.py plus deprecation -- worth looking at).

* Breakpoint improvements:

  * Make it possible to create an internal breakpoint from Python.

  * Add a bit to breakpoints to make the breakpoint "maybe non-stopping"
    -- in the sense that when the breakpoint is hit, it will call an
    attached Python function, and if the function returns True, the
    breakpoint will not stop.  This would be different from "commands"
    including "cont" in that it would not interfere with step or next.
    (You can fake this right now by doing work via a convenience
    function attached to the breakpoint condition -- but that is gross
    and user-visible.)

  * Use these two new features to write a command to create a "return"
    breakpoint.  This is a breakpoint that fires when a function
    returns.  (I think you can do this by putting a breakpoint at the
    function's entry, then going up and looking at the outer frame's
    PC, or something along those lines.  Bonus points for interacting
    properly with longjmp and throw...)

* Minimal systemtap integration.  In particular I've been thinking it
  would be nice if gdb could read and use systemtap probe points.  This
  doesn't have to be written in Python, but it seems like a nice
  experiment.  Some sub-tasks:

  * Hooking into linespecs so users can write "probe:name" to refer to a
    systemtap probe.  This would also mean dealing with completion,
    maybe some ugly linespec refactoring.

  * Let Python code access the contents of a section in an objfile.

* Make a new Expression object that represents a parsed expression.
  Add a new gdb.parse method to create these, something like:

    gdb.parse (EXPR, [BLOCK], [STOP_AT_COMMA]) -> gdb.Expression

  This functionality is handy for writing certain kinds of commands.

* Frame and "new-backtrace" cleanup

  * Clean up the frame wrapper and iteration code to solve problems
    reported on the Archer list; look at the various use cases posted
    there to make sure they can all be handled.  This may mean adding
    more methods to Frame so we can avoid having a FrameWrapper at all.

  * Add a feature to new-backtrace to print the objfile name for a
    frame.  (This might be a request in bugzilla somewhere.)

  * Rewrite the "upto" family of commands.  They are ok but there were
    some ideas on the Archer list about how to improve them.

  * Give frame wrappers, or their replacement, some notion of being
    synthetic and having "original" sub-frames.  The idea here is to
    provide multiple views of the stack, as a start toward debugging
    scripting languages.  Provide versions of up/down/etc that work on
    the filtered view or the raw view, enhance new-backtrace to display
    sub-frames indented or something like that.  Figure out how to
    present this via MI.

* True scripting language debugging.  This is a big goal that requires a
  lot of infrastructure, some already listed above.

  * Hook into linespecs so that "break x" can call into the scripting
    support code.

  * Hook into "watch" so the python code can do the right thing.

  * Hook into expression parsing.  Maybe this could be done by letting
    people write new languages in Python.

  * Frame-based operations (up/down/etc) -- see above.

  * Hook into step/next/finish as needed.

* New commands and functions I've wanted:

  * "log-expression".  Like a combination between "break" and "printf",
    would trace expressions at some point in the code, without
    interfering with "next".  (Needs at least the expression parsing
    stuff and a breakpoint enhancement.)

  * Finish "info mutex".  The one posted to the list is a little dumb;
    it could be made more robust by using the systemtap probes in the
    mutex functions.  With Oguz's work we would also have a way to look
    for deadlocks.

  * "declare $var : type" - make $var a reference to
    *(type*)malloc(sizeof(type)).  I'm not sure this one is super
    useful, but it might make scripting gdb a little easier sometimes.

  * PR 8320, recursive version of "directory" command.

  * New function "$memoize".  It would memoize strings in the inferior,
    so that they aren't constantly re-allocated.  Useful when using a
    string in a breakpoint condition.  This would need Oguz's work since
    the cache would have to be invalidated when the inferior is
    restarted.

Tom