Re: Python API plans

[André Pönitz <andre dot poenitz at nokia dot com>]

On Tuesday 24 August 2010 03:06:40 ext Tom Tromey wrote:
> 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;

Puh, that's quite a bit.

> 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.

I think inferior interaction (run/stop stuff) and breakpoint access are the 
big "missing" areas in Python support. From a frontend's point of view
the missing "run control" is actually not that bad as it is sufficiently 
well supported by MI (in contrast to breakpoints), but from a CLI/Python
user's point of view the priorities are probably inverted.

> * Fix all open bugs.

I am not sure whether e.g.

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

really deserves a "Pythonic fix" as long as there are real problems
around that don't have obvious (if any) workarounds.
 
> * 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.

Similar here. The effective gain seems limited, especially since quite
a bit of the MI commands are not optimal themselves. As a really awful
example: "-data-read-memory" produces a lot of unneeded "information"
yet is so slow that a "dump binary memory"/read-from-file combination
easily beats it by a factor of two or three. That behaviour should not 
be wrapped in Python.

I could imagine handling that item on a case-by-case base and spending
an extra thought or two on each individual API might make more sense.

> * 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).

I have no opinion on these.

> * 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.)

I haven't looked at Python breakpoint handling for a while, MI is
certainly missing feedback about multiple breakpoints, and gdb as
a whole seems to be missing some user visible feedback when
pending breakpoints.

>   * 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...)

Maybe the issue discussed in http://cygwin.ru/ml/gdb/2010-03/msg00116.html
could be resolved in the way "everybody" expects, too? ;-)

> [snip] 
>   * Let Python code access the contents of a section in an objfile.

That would be nice indeed.
 
> * 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.

What's the use case? Keeping "anything" on the inferior side?

> [snip]
>   * "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.

I have a similar construct five times in my code (creating an initialized
gdb.Value, but that 'declare' is the first step) I think having it handled
in gdb would be nice, especially if it relieves me from figuring out
when to add 'class ' to the type, and when to quote it etc to 'survive'
gdb command line parsing.

Another open issue in the area is to provide a way to keep (structure)
return values of inferior calls alive in the inferior. Right now the only way 
I am aware of to chain or nest inferior calls is to poke data back manually.

From a quick glance,

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

seem to be related.

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

That's not solvable using "set substitute-path"?

But anyway, it would be nice if gdb was able to tell the user that it did
not find a file, or that it had to guess and is not sure the guess is right,
and ideally even provide some means to query for user advice in that
situation.

Looks like you have a lot of work ahead.

Andre'