Differences between revisions 24 and 25
Revision 24 as of 2013-06-17 17:14:08
Size: 3225
Editor: TomTromey
Comment: add ongoing-work category link
Revision 25 as of 2013-06-17 17:24:12
Size: 3234
Editor: TomTromey
Comment: tweak the category
Deletions are marked like this. Additions are marked like this.
Line 58: Line 58:
OngoingWork category:OngoingWork


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

Getting the code / Helping

Almost all the code from the old development branch has been merged to GDB CVS. The simplest way to get the code is to check out from CVS. New work should be done using CVS HEAD as a baseline.


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

  • 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 these, or use gdb -nx. They come from debugging aids specific to debugging GDB under itself.

Example code

There are some useful examples in the source tree. Look in src/gdb/python/lib/gdb. (The old tromey/python branch in the archer git repository still has some code here that has not been merged. See this thread for info on why some of it needs more work.)

Current Roadmap

The medium-term roadmap we are working on is in this email message.

Things we want to work

In addition to the medium-term roadmap, here are some other areas where we would appreciate help. There is some overlap.

  • 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)

    See PR7221 as well.

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.