This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

summary of python scripting in gdb


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
  parameters.
* Commands.  You can invoke arbitrary gdb commands, and write your own
  commands.
* 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
  as well.


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
support:

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

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]