Differences between revisions 2 and 3
Revision 2 as of 2008-07-06 20:03:59
Size: 1536
Editor: TomTromey
Comment: Reformat
Revision 3 as of 2008-07-06 20:10:32
Size: 2116
Editor: TomTromey
Comment: update to-do list
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
 * Values need a rewrite so that they are simpler to manipulate from Python.  * Values need a rewrite so that they are simpler to manipulate from Python.  (Thiago is doing this.)
Line 18: Line 18:
 * There should be a Python class representing a language and all methods should be overrideable.
 * We need documentation for the Python API.
 * We need 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.
 * We need a way to automatically load Python code that is shipped with a given shared library or executable. One idea here is to store it alongside the (separated) debuginfo.

PythonGdb

This page describes the work to integrate Python scripting into Gdb.

Things that work

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

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

  • Breakpoints, blocks, frames, symbols, symbol tables, and values have Python representations. Some of these representations are not finalized (in particular values will definitely change).
  • You can tell MI to use a Python function to change how a particular type of object is displayed.

Things we want to work

  • Values need a rewrite so that they are simpler to manipulate from Python. (Thiago is doing this.)
  • Types need to be represented in Python.
  • It should be possible to override CLI printing of a value using Python. In particular code for this should be distributed with a library or executable and automatically found. Pretty-printing should be the default, with a new /r (raw) flag to print that bypasses the display.

  • Expressions should be represented in Python.
  • There should be a Python class representing a language and all methods should be overrideable.
  • We need documentation for the Python API.
  • We need 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.
  • We need a way to automatically load Python code that is shipped with a given shared library or executable. One idea here is to store it alongside the (separated) debuginfo.

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.