Differences between revisions 26 and 27
Revision 26 as of 2013-06-17 17:27:48
Size: 3225
Editor: TomTromey
Comment: revert the tweak
Revision 27 as of 2013-12-04 18:03:08
Size: 2084
Editor: TomTromey
Comment: rewrite
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
== 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.

== 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}}}.
 * 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}}} [[http://sourceware.org/git/gitweb.cgi?p=archer.git;a=shortlog;h=refs/heads/tromey/python|branch in the archer git repository]] still has some code here that has not been merged. See [[http://sourceware.org/ml/archer/2009-q3/msg00235.html|this thread]] for info on why some of it needs more work.)
Line 28: Line 7:
The medium-term roadmap we are working on is in [[http://sourceware.org/ml/gdb/2010-08/msg00139.html|this email message]].  * Fix [[https://sourceware.org/bugzilla/buglist.cgi?component=python&list_id=12545&product=gdb&resolution=---|bugs in the python component in bugzilla]]
Line 30: Line 9:
== Things we want to work ==  * Expressions should be represented in Python. This may consists of two parts:
   * A simple API to parse an expression, yielding an {{{Expression}}} object which can be evaluated later
   * A full API to construct new {{{Expression}}} objects by hand
Line 32: Line 13:
In addition to the medium-term roadmap, here are some other areas where we would appreciate help. There is some overlap.  * Resurrect the old {{{upto}}} command and implement general "framespecs". The idea here is to let users have simpler ways to navigate stack frames, like "go up to the frame in eval.c". Bonus points if framedescs interact properly with frame filters, and if framedescs themselves are readily hackable from Python.
Line 34: Line 15:
 * 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:
 * Scripting language debugging. This is a big goal with many parts.
   * Virtualize linespecs so that Python code can define their meaning. This could either be pure overrides (when in a filtered frame for a scripting language) or linespec extensions, or both.
   * Virtualize the {{{watch}}} command for a scripting language
   * Virtualize expression parsing. Requires some form of the expression API
   * Virtualize the infrun commands (e.g., {{{next}}})
   * Update frame filters to let them return a Python object representing a language. This would be one way to hook into the various virtualizations
Line 43: Line 22:
  {{{
<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)
}}}
 * Add inferior control API. This means ways to {{{next}}}, {{{step}}}, etc, a thread, perhaps also with fine-grained control over the other threads
Line 47: Line 24:
 See Sourceware: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
 * Make {{{import gdb}}} work from an ordinary Python interpreter. This is can be done relatively easily by compiling gdb {{{-fPIE}}} and arranging via visibility to only export the module-initialization function. This will require some startup changes and also an API to the event loop. See the python/pie branch [[https://gitorious.org/binutils-gdb/|here]] for the start.

PythonGdb

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

Current Roadmap

  • Fix bugs in the python component in bugzilla

  • Expressions should be represented in Python. This may consists of two parts:
    • A simple API to parse an expression, yielding an Expression object which can be evaluated later

    • A full API to construct new Expression objects by hand

  • Resurrect the old upto command and implement general "framespecs". The idea here is to let users have simpler ways to navigate stack frames, like "go up to the frame in eval.c". Bonus points if framedescs interact properly with frame filters, and if framedescs themselves are readily hackable from Python.

  • Scripting language debugging. This is a big goal with many parts.
    • Virtualize linespecs so that Python code can define their meaning. This could either be pure overrides (when in a filtered frame for a scripting language) or linespec extensions, or both.
    • Virtualize the watch command for a scripting language

    • Virtualize expression parsing. Requires some form of the expression API
    • Virtualize the infrun commands (e.g., next)

    • Update frame filters to let them return a Python object representing a language. This would be one way to hook into the various virtualizations
  • Add inferior control API. This means ways to next, step, etc, a thread, perhaps also with fine-grained control over the other threads

  • Make import gdb work from an ordinary Python interpreter. This is can be done relatively easily by compiling gdb -fPIE and arranging via visibility to only export the module-initialization function. This will require some startup changes and also an API to the event loop. See the python/pie branch here for the start.


OngoingWork

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.