Differences between revisions 18 and 19
Revision 18 as of 2009-05-20 20:45:13
Size: 4121
Editor: c9521ca2
Comment: Add a "hints" section.
Revision 19 as of 2010-09-14 07:48:52
Size: 4181
Editor: 210-121-92
Comment: Link to PythonGdbTutorial
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
This page describes the work to integrate Python scripting into Gdb. This page describes the work to integrate Python scripting into Gdb. For a short tutorial of new features see PythonGdbTutorial.

PythonGdb

This page describes the work to integrate Python scripting into Gdb. For a short tutorial of new features see PythonGdbTutorial.

Getting the code / Helping

Discussions are going on in both the GDB and Archer mailing lists, and code for this effort is being held in the Archer git repository. See the ProjectArcher page for details on checking out Archer. The Python branch is named archer-tromey-python.

To get it, first clone the archer repository using one of the following commands:

  • git clone git://sourceware.org/git/archer.git

  • git clone ssh://sourceware.org/git/archer.git

Then you can checkout the python branch with:

cd archer; git checkout --track -b python origin/archer-tromey-python

If you are interested in helping out, and you have an FSF assignment on file, we can set you up with write access.

Hints

  • Most of the Python API is documented in <python-branch-src>/gdb/doc/gdb.texinfo. You can get a nice PDF file with make gdb.pdf.

  • If you try to use the Python scripts included in the branch, you'll have to start GDB from the python-branch-build/gdb/ directory, since there's a .gdbinit file there which contains some magic sauce to make it work (this won't be necessary in the final upstream version).

    • Unless you're debugging GDB itself, you'll see errors like:
      Function "internal_error" not defined.
      Make breakpoint pending on future shared library load? (y or [n])
      [answered N; input not from terminal]
      You can safely ignore them. They come from debugging aids specific to debugging GDB under itself.

Things that work

  • You can create new gdb commands by subclassing gdb.Command

  • You can create new convenience functions by subclassing gdb.Function

  • You can create new gdb parameters by subclassing gdb.Parameter

  • Breakpoints, blocks, frames, symbols, symbol tables, types, and values have Python representations. Some of these representations are not finalized.
  • You can write a type-specific pretty-printer that will work with MI or the CLI; this lets you more intelligently display the contents of objects
  • Python code can be auto-loaded based on an objfile's file name. This works with the separate debuginfo feature as well. (See the manual for details.)
  • gdb has a new -P flag. This enables using gdb as a python scripting interpreter, that is, starting scripts with #!.../gdb -P.

Example code

There are some useful examples in the source tree. Look in src/gdb/python/lib/gdb.

Things we want to work

  • Python code should be able to detect why the inferior has stopped.
  • Expressions should be represented in Python.
  • There should be a Python class representing a language and all methods should be overrideable.
  • There should be a Python class representing a target and all methods should be overrideable.
  • We need more documentation for the Python API.
  • We need more test cases for the Python API.
  • We need a library of useful Python code, in particular useful user-defined functions. Maybe this library needs some kind of auto-loading support -- we want to keep startup time short.
  • Nice feature: be able to register a python signal handler for inferior signals. Would help in this usecase:
    • <LimCore> how to run gdb from command line, so that it will run ./foo.bin  with arguments: foo bar baz   and it will run it instantly without waiting for 'r'; And if program segfaults then it will do 'bt' without waiting for the command.  (and if program terminates normally then it will also just quit)

Big Goals

  • It should be possible to write support for a new language entirely in Python.
  • It should be possible to rewrite Insight in Python.
  • It should be possible to write useful "executables" purely in Python. This would mean modifying the gdb startup sequence (so a script could be used in a pipeline) and maybe adding command-line options. One example of a tool like this would be a generalized strace, like frysk's ftrace.

  • ... your idea here

None: PythonGdb (last edited 2013-12-04 18:03:08 by TomTromey)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.