Re: Inferior python debugging: working prototype

[Tom Tromey <tromey at redhat dot com>]

David> I've now got working gdb python code for prettyprinting the various
David> types seen when the inferior process is linked against libpython, such
David> as for debugging the python binary itself (or presumably a build of gdb
David> itself, though I haven't tried that).

Very cool.

David> I am still seeing the issue described in that post where variables of
David> interest are visible from within the regular (gdb) interface, but not
David> visible from python's gdb.selectedframe.read_var() (specifically, the
David> PyFrameObject *f within PyEval_EvalFrameEx; which appears to be an issue
David> with an inlined frame of C code).

Could you file this in bugzilla?  If it works from the CLI then there
should be some way to access it from Python.

David>   - I want the prettyprinter hooks to be used by default on Python
David> backtraces in Fedora 13, so that (for example) automated tools that
David> capture backtraces contain this rich debugging information. What's the
David> best way of wiring this up so that the module is imported?  Is something
David> like this happening for the GLib/GTK hooks, or for the STL?

See the Auto-loading and Selecting Pretty-Printers nodes in the manual.
I think they describe it fairly well.

The libstdc++ printers are all set up to work this way.  If you read the
libstdc++ "hook file", it is full of a lot of goo you may not need,
because upstream GCC wants its install tree to be relocatable.  If you
don't care about that you can shrink the file down to a couple of lines.

David>   - should this be distributed as part of gdb or part of python?  (it
David> handles both python2 and python3, mostly, at any rate)

Ideally, IMO, with Python.  In general I think the only way to scale
this up to lots of libraries is to maintain the custom code alongside
its project.

Right now, in Fedora, we are distributing the libstdc++ printers in the
gdb RPM, but I think (hope) we will be changing that.  I don't really
remember the detailed reason for this decision, but basically it was
expediency.

David>   - I'd like to be able to automatically test this.  Am I right in
David> thinking that it's reasonable to assume that given that a gdb configured
David> with --with-python can also be tested debugging that instance of python
David> (I'd also like to automate testing of python3 support, which would be a
David> different runtime)

I'm not sure I understand the potential issue.

There should be no problem using python-enabled gdb with these printers
to debug a second instance of itself, or of any other program using
python.

David>   - to what extent is a pretty-printer expected to return in a
David> sane amount of time and use sane amounts of RAM?

What I recommend is trying to write your printers so that they work
lazily.  That is, don't precompute the proxy objects, have your
printer's children method return an iterator that computes them lazily.

GDB will only ask for the children it intends to print, as determined
either by user settings in the CLI (e.g., "set print elements") or by UI
requests to limit the number of varobj children in MI.

This may not always be easy; if it really isn't possible I am not sure
what you could do.  The problem is that if your printer limits the
output, there is no way to request more.

Tom