This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dmalcolm
Recipients davidfraser, dmalcolm, gregory.p.smith, jyasskin, loewis, scott.tsai
Date 2010-04-01.02:34:51
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1270089304.84.0.082734892182.issue8032@psf.upfronthosting.co.za>
In-reply-to
Content
I'm attaching a new version of the patch (v5), against svn trunk (r79517)

I've been testing these hooks by using "gdb attach" to attach to real-world python programs.

When doing this with earlier versions of the hooks, gdb would pause for many seconds when printing some values (e.g. during a backtrace).  The issue was that "proxyval" scrapes the entire graph of python objects from the inferior process into gdb, and then prints it.  As well as being slow, this can be many pages of textual output.

To counter this, I've rewritten the pretty-printers to use a stream-based approach.  The various PyObjectPtr subclasses have a "write_repr" method that writes the represenation to a file-like object whilst they recurse.  I supply a file-like object "TruncatedStringIO", which raises an exception after a limit is reached: by default 1K of string data.  (some simple subclasses simply reuse repr(self.proxyval()) for this, but objects that can follow cross-references have their own write_repr implementation).

I've also rewritten frame handling: I eliminated the FrameInfo class, moving its functionality to the PyFrameObjectPtr class, and introduced a new "Frame" class to wrap gdb.Frame.  This allowed a big simplification of the extension commands, and fixed various bugs (involving inlining and optimization)

Within the py-up/py-down and py-bt commands, the code now prefixes Python frame printing with C-level frame indexes, to better tie together the C-level and Python-level views of the stack.

I've added a couple of new commands:
  * "py-print" - takes a string argument.  It attempts to look up the Python variable with that name, and print its value  (it searches first in the locals of the current frame, then globals, then builtins).
  * "py-locals" - prints Python local variables; an analog of gdb's "info locals"

Other changes since v4:
  * Add a ">" marker to the output of "py-list", indicating the current location
  * Add pretty-printer for PyCFunctionObject ("built-in function" and "built-in method")
  * Add selftests for the above
  * Make frame printing fetch information on locals on demand, rather than within FrameInfo's __init__ method (the latter is completely gone)
  * Introduce PyObjectPtr.pyop_field method, simplifying the code
  * Change the set/frozenset selftests to remove a reliance on ordering within the representation of the members
  * Try to be more robust for the case where PyEval_EvalFrameEx's "f" parameter is optimized out (see https://bugzilla.redhat.com/show_bug.cgi?id=556975 )
  * Remove the FIXME in PyLongObjectPtr: I've tested the code on builds with both sizeof(digit) == 2 and == 4
  * More selftests for unicode printing

All tests pass on my box (Fedora 12 x86_64 with gdb-7.0.1-33.fc12.x86_64): "Ran 45 tests in 17.439s"
History
Date User Action Args
2010-04-01 02:35:07dmalcolmsetrecipients: + dmalcolm, loewis, gregory.p.smith, davidfraser, jyasskin, scott.tsai
2010-04-01 02:35:04dmalcolmsetmessageid: <1270089304.84.0.082734892182.issue8032@psf.upfronthosting.co.za>
2010-04-01 02:35:03dmalcolmlinkissue8032 messages
2010-04-01 02:35:02dmalcolmcreate