Installing a Python-enabled debugger
We’ll start at the very beginning: checking it out, building it, and then “hello, world”.
Writing a new gdb command
I'll show you how to implement a new command to save breakpoints to a file.
gdb convenience functions
Now we’ll see how to write new functions, so your Python code can be called during expression evaluation.
Parameters, and extending require
Parameters are a nice feature when you are polishing your gdb extensions for more general use. Having Python extensions which are themselves extensible - like require - is an emerging theme of python-gdb.
The filtering backtrace
Now let’s do something really useful. We’ve reimplemented backtrace, entirely in Python. And, in so doing, we’ve added some functionality, namely filtering and reverse backtraces
Auto-loading Python code
Suppose someone writes a new filter - it would be nice to get it without having to edit anything. Naturally, we provide an automatic mechanism for loading code.
Pretty printing, part 1
You can register a pretty-printer class by matching the name of a type; any time gdb tries to print a value whose type matches that regular expression, your printer will be used instead.
Pretty printing, part 2
There are a few additions which are helpful with more complex data types. This post will explain the other printer methods used by gdb, and will explain how pretty-printing interacts with MI, the gdb machine interface.
In this post I want to look at gdb from a different angle: as a library. I’ve long thought it would be pretty useful to be able to use gdb as a kind of scriptable tool for messing around with running programs, or even just symbol tables and debug info; the Python work enables this.
What could be flashier than a GUI?
What next? Now is an exciting time to be working on gdb. There are a number of very interesting projects underway.
Gdb's event system.
API for handling breakpoints.