New submission from Dave Malcolm <dmalc...@redhat.com>: gdb 7 can be extended with Python code, allowing the writing of domain-specific pretty-printers and commands.
I've been working on gdb 7 hooks to make it easier to debug python itself, as mentioned here: https://fedoraproject.org/wiki/Features/EasierPythonDebugging I'm attaching a patch for merger with "trunk". My hope is to be the maintainer of this work, although I do not yet have SVN commit rights (see http://mail.python.org/pipermail/python-committers/2010-February/000711.html ) The code is fully compatible with the existing "Misc/gdbinit" macros - you can freely use both as needed. = Two versions of Python = This code is intended to run inside gdb. There are potentially two Python versions involved here: that of the "inferior process" (the one being debugged), and that of the debugger. As I understand things, gdb only supports embedding Python 2 at the moment. This code is thus targeting that version of Python. So far, I've attempted to keep this code so that it will run when the "inferior process" is either Python 2 or Python 3. I could vary this code in the py3k branch if desired. The code would then track the "inferior process" version of Python, so that code to debug Python 3 would live in the py3k branch. That code would still be written for Python 2, though. = Makefile changes = The Makefile installs the gdb hooks to -gdb.py relative to the built python (even if you're not using them), which some may find irritating. It needs to do this for the test_gdb.py selftest to work (and for the gdb hooks to be usable if you're actually using them to debug your build of Python). Should I write a gdb configuration test to check for the availability of gdb built with python? I've added the file to .hgignore and .bzrignore. IIRC, a similar thing can be done to the SVN metadata (I don't think this is expressable as a patch, though). Alternatively, I could wire up the gdb tests to load the file from its location in the source tree. However, I intend for this code to be installed to a location alongside the build Python, so that it can be automatically detected and used by gdb. Typically this means copying it to the path of the ELF file with a -gdb.py file. In my RPM builds I add an extra copy, locating it relative to the location of the stripped DWARF data (e.g. /usr/lib/debug/usr/lib64/libpython26.so.1.0-gdb.py) = Selftests = The selftest runs whatever version of "gdb" is in the path, which then invokes the built version of python, running simple "print" commands and verifying that gdb is corrrectly representing the results in backtraces (even in the face of corrupt data). I haven't fully tested the error cases yet (e.g. for when gdb is not installed). The tests take about 14 seconds to run on my box: [da...@brick trunk-gdb]$ time ./python Lib/test/regrtest.py -v -s test_gdb The CWD is now /tmp/test_python_19369 test_gdb test_NULL_ob_type (test.test_gdb.DebuggerTests) ... ok test_NULL_ptr (test.test_gdb.DebuggerTests) Ensure that a NULL PyObject* is handled gracefully ... ok test_classic_class (test.test_gdb.DebuggerTests) ... ok test_corrupt_ob_type (test.test_gdb.DebuggerTests) ... ok test_corrupt_tp_flags (test.test_gdb.DebuggerTests) ... ok test_corrupt_tp_name (test.test_gdb.DebuggerTests) ... ok test_dicts (test.test_gdb.DebuggerTests) ... ok test_getting_backtrace (test.test_gdb.DebuggerTests) ... ok test_int (test.test_gdb.DebuggerTests) ... ok test_lists (test.test_gdb.DebuggerTests) ... ok test_long (test.test_gdb.DebuggerTests) ... ok test_modern_class (test.test_gdb.DebuggerTests) ... ok test_singletons (test.test_gdb.DebuggerTests) ... ok test_strings (test.test_gdb.DebuggerTests) ... ok test_subclassing_list (test.test_gdb.DebuggerTests) ... ok test_subclassing_tuple (test.test_gdb.DebuggerTests) This should exercise the negative tp_dictoffset code in the ... ok test_tuples (test.test_gdb.DebuggerTests) ... ok test_unicode (test.test_gdb.DebuggerTests) ... ok ---------------------------------------------------------------------- Ran 18 tests in 13.233s OK 1 test OK. [36833 refs] real 0m13.599s user 0m11.771s sys 0m1.384s = Platform support = I don't have access to anything other than Linux, so I've no idea how well this stuff works on other platforms. My testing so far has been on Fedora, though I've heard of successful usage of this on Debian. = Legal stuff = Earlier versions of this code were licensed under the LGPL 2.1 I'm relicensing the code to be "under the same license as Python itself", assuming that's legally OK. Do I need to state that in the file header, or is that redundant? I'm in the process of doing the PSF Contributor Agreement paperwork (as an individual); waiting to get my hands on a fax machine. My employer, Red Hat, has agreed for me to retain copyright on all contributions I make to Python. ---------- components: Demos and Tools messages: 100226 nosy: dmalcolm severity: normal status: open title: Add gdb7 hooks to make it easier to debug Python versions: Python 2.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8032> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
