This is the mail archive of the
mailing list for the Archer project.
summary of python scripting in gdb
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Cc: Eric Bachalo <ebachalo at redhat dot com>
- Date: Wed, 25 Feb 2009 15:15:48 -0700
- Subject: summary of python scripting in gdb
- Reply-to: Tom Tromey <tromey at redhat dot com>
Eric asked me for a summary of the python scripting capabilities in
archer, and I figured I would CC the list in case I missed anything.
Eric, if you have unanswered questions when you reach the end, let me
know and I will answer them.
We've taken a general approach of writing Python classes and functions
that wrap various internal gdb modules. Some of these wrappers are
reasonably complete and robust, while others are fairly minimal.
Modules that we have wrapped:
* Parameters. You can get and set gdb parameters, and write your own
* Commands. You can invoke arbitrary gdb commands, and write your own
* Values. You can do a number of operations on inferior values.
* Types. You can inspect inferior types in various ways.
* Functions. We added "convenience functions" to gdb; these are
similar to convenience variables, but are functions written in
Python. This lets you insert scripting into expression evaluation.
* Breakpoints, Frames, Objfiles, Symbols, Symtabs, Threads. A bunch
of gdb structures that have Python wrappers. Some of these are
reasonably complete (breakpoints), some less so (objfiles).
These wrappers provide the basic glue between Python and gdb. But we
also added a few specialized interfaces.
* We added a new "-P" (aka --python) option to gdb. This puts gdb in
a special python batch mode. It lets you write scripts in Python
that start "#! /usr/bin/gdb -P".
* We added a simple event-posting capability to the gdb main loop.
Because gdb's implementation is not thread-safe, all gdb commands
must be executed in its main thread. This functionality lets you
submit work on the various gdb modules by submitting a request to
the gdb thread from some other thread.
* Auto-loading. We've set things up so that some Python code can be
automatically loaded when gdb reads an objfile. This lets
application- or shared-library-specific code work automatically.
E.g., we'll ship the libstdc++ pretty-printers in such a file, so
that they will automatically be available to the user when debugging
any program that uses libstdc++.
* Pretty-printing. We hooked into the gdb value-printing code and let
Python take a first crack at formatting a value. This works for MI
That is a bit abstract. To give you an idea of what this enables,
here are things we've already written using the existing Python
* A complete suite of pretty-printers for the containers in libstc++.
* A few fun, simple commands:
* Save breakpoints. This is frequently requested on the gdb list.
* A simple "pahole" analog. Shows fillable holes in data structures.
* A way to ignore errors from some other gdb command -- very handy
in gdb scripting, also semi-frequently requested.
* A convenience function that can be used to match the function name
of functions on the stack. This lets you write a breakpoint that is
conditional on the sequence of callers.
* A filtering backtrace implementation. User code (say, something
auto-loaded) can supply a filter that can manipulate the frames
returned before printing a backtrace.
One way to use this is to supply a filter for an interpreter that
makes interpreter stack frames look like frames representing the
code that is being interpreted.
* A little sample program that starts a Gtk main loop in a separate
thread and shows a window. You can do stuff with this window while
gdb waits for user input.
There is still a lot you can't really do easily.
E.g., suppose you wanted to fully control the inferior from Python,
for automated testing or something. Well... we don't have a way to
invoke Python code when the inferior stops for some reason, there's no
way to find out why the inferior stopped, there isn't much control
over gdb's own I/O, etc.
We've mostly tried to drive development according to features we'd
like, and in particular we focused a lot of effort on pretty-printing.
I think we'll do all the other stuff eventually, we just need some
time and perhaps some nice targets to aim for.