This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Python API plans
- From: Tom Tromey <tromey at redhat dot com>
- To: GDB Development <gdb at sourceware dot org>
- Date: Mon, 23 Aug 2010 19:06:40 -0600
- Subject: Python API plans
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