One goal I have for integrating Python scripting into gdb is to be able to fully control gdb from Python. I’ve made a few steps toward this recently. Today I can do:
#! /home/tromey/gnu/python-gdb/build/gdb/gdb --python import sys, gdb from hack import inferior child = inferior(sys.argv) if not child.run(): gdb.execute("bt 5") gdb.cli()
This is a short script that is marked executable. With this, I can invoke “
stop-if-broken my-program arguments“. This will run the program; if it dies for some reason, it will print a stack trace and bring up the gdb command line. Otherwise, it exits.
I like to think you can already see the future of gdb here, though. And although this is pretty young, you can easily extend it a bit — for instance, you could add breakpoints between creating the inferior and starting it. Still, don’t be totally fooled; this is still a toy and there is a lot to do on the gdb side.
hack” stuff is because I have no clue about intelligently managing Python packages. I’m looking for a good guide here. What I really want to do, I think, is have classes like
Breakpoint, etc, directly in the gdb namespace, but I don’t want everything in one huge file. Or is this javathink? Writing “
import gdb.inferior.Inferior” feels weird. (If you’re going to give me advice — which I really want — there is an added wrinkle, which is that the
gdb module is created directly in the C code in gdb.)