On Tue, 2013-04-09 at 11:22 +0100, Michael Meeks wrote: > Hi guys, > > On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote: > > CCing David Malcolm. > > > > Michael> (gdb) py-bt > > > > I just wanted to mention here that Phil Muldoon is working on a "frame > > filter" patch series that is basically "pretty printing for stack > > frames". With this in place you'll no longer need a special command -- > > with appropriate support from Python, you'll be able to see interpreted > > frames interleaved with the low-level C frames. > > Oh - nice ! :-) > > > This series is nearing final review now and should appear in gdb 7.7, > > later this year. > > Excellent news indeed. > > > I think we're planning to rewrite the existing "py-bt" code into frame > > filter form ourselves. > > So - in which case this significantly reduces the problems of using > python for debugging; I assume that with py-bt - there are still issues > with interleaving two tools for printing parts of backtraces when we > call several times to and fro between C++ and python. > > > Eventually we'd like to have more full support for "mixed" interpreter > > and C debugging. However this is a ways off. > > For me, clearly seeing the python line numbers is the key rather than > the interpreter details - we treat python itself as working black-box - > and the script itself as the problem ;-)
Aha. Sorry; I came into this discussion halfway though. I wrote the Python gdb hooks for CPython itself (i.e. "py-bt" and others). You can see documentation for them here: http://docs.python.org/devguide/gdb.html#gdb-7-and-later In particular: (gdb) py-list should give you python source code for the current python frame. > > So - re-examining my requirements: > > > + debug-ability - when the test fails - and the best tests are > > written to fail regularly ;-) we need to be able -very-simply- > > to get a backtrace we can work with - without a ton of > > training, reading a dozen wiki pages, poking for obscure > > symbols, etc. > > Michael - as/when a python unit test fails - can we make the magic > environment variables that are listed include some debugging > instructions that include the "py-bt" detail etc. so that everything > needed is in the failure message ? when we're in the automatic trace > collection mode (I forget what env. var that is) do we dump the python > pieces as well ? Also - can we distribute / include / install the magic > that makes 'py-bt' work - not sure it works for me (on openSUSE - at > least a facile start gdb, type py-bt fails in spades ;-) On Fedora we package the python-gdb.py code so it appears in the python-debuginfo rpm and is in the correct path so that it gets autoloaded by gdb when libpython2.7.so is debugged. Specifically (quoting Fedora's python3.spec): # We install a collection of hooks for gdb that make it easier to debug # executables linked against libpython3* (such as /usr/bin/python3 itself) # # These hooks are implemented in Python itself (though they are for the version # of python that gdb is linked with, in this case Python 2.7) # # gdb-archer looks for them in the same path as the ELF file, with a -gdb.py suffix. # We put them in the debuginfo package by installing them to e.g.: # /usr/lib/debug/usr/lib/libpython3.2.so.1.0.debug-gdb.py # # See https://fedoraproject.org/wiki/Features/EasierPythonDebugging for more # information # # Copy up the gdb hooks into place; the python file will be autoloaded by gdb # when visiting libpython.so, provided that the python file is installed to the # same path as the library (or its .debug file) plus a "-gdb.py" suffix, e.g: # /usr/lib/debug/usr/lib64/libpython3.2.so.1.0.debug-gdb.py # (note that the debug path is /usr/lib/debug for both 32/64 bit) # # Initially I tried: # /usr/lib/libpython3.1.so.1.0-gdb.py # but doing so generated noise when ldconfig was rerun (rhbz:562980) # %if 0%{?with_gdb_hooks} DirHoldingGdbPy=%{_prefix}/lib/debug/%{_libdir} PathOfGdbPy=$DirHoldingGdbPy/$PyInstSoName.debug-gdb.py mkdir -p %{buildroot}$DirHoldingGdbPy cp Tools/gdb/libpython.py %{buildroot}$PathOfGdbPy %endif # with_gdb_hooks > > + that backtrace should not have big, opaque chunks that > > are either empty (cf. Java) or point to random / irrelevant > > pieces of C/C++ interpreter code - Python / StarBasic & > > others. It should allow interactive inspection of variables > > up and down the stack. > > It seems that this is getting towards working on modern Linux systems. > Do we get variable inspection sorted out there as well ? py-locals py-print > > + reliability and performance: new unit tests should be small, > > fast, non-duplicative (ie. re-using existing code & > > frameworks) > > I guess re-using the existing C++ test code / bootstrapping framework > mostly avoids duplication here; and either way unit tests are (sadly) > one of the more duplicative pieces of code we have. The issue you may run into is that, at sufficiently high optimization levels on x86_64, gdb's python hooks can have trouble locating the PyFrameObject* within the C locals of the relevant C frame, and without that, the "py-" commands can't work. I've tried to make them fail gracefully. > > + ideally - the unit tests should run -in-the-same-process- > > which significantly helps with the above performance, > > debugging, reliability and more. > > And this is now fixed; so - David & Michael - thanks for working on > this - looks like a good solution with a brighter future :-) Hope the above is helpful Dave _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice