Differences between revisions 3 and 4
Revision 3 as of 2008-07-06 20:10:32
Size: 2116
Editor: TomTromey
Comment: update to-do list
Revision 4 as of 2008-07-16 22:52:31
Size: 2547
Editor: c9527cb4
Comment: add feature idea
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
 * 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)
}}}

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