This page describes the work to integrate Python scripting into Gdb. For a short tutorial of new features see PythonGdbTutorial.
- 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.