Thanks for reviewing the patch.

I've changed the pretty-printing of NULL pointers to "0x0" as suggested, and I've updated frame printing.  Frames are now printed like this
(gdb) p f
$1 = Frame 0x827e544, for file /home/david/coding/python-gdb/crasher.py, line 19, in <module> ()

...so that in a gdb backtrace you might see:
#18 0x080f9aab in PyEval_EvalFrameEx (f=Frame 0x827e544, for file /home/david/coding/python-gdb/crasher.py, line 19, in <module> (), throwflag=0) at Python/ceval.c:2665

Is this what you had in mind?

As for the use of the word "remote",this is mostly for my own sanity, but I suspect it is needed.  My rationale for this is that there are two address spaces at play: the local address space with the gdb process, and the remote one within the inferior process.  It's possible for addresses with the gdb process to be printed for any object with a NULL tp_repr in its class, and if it were, it would be confusing which address space is it.

For example, if within gdb I run this command:
(gdb) python print repr(gdb.selected_frame())
<gdb.Frame object at 0xb753ef98>

the hexadecimal value that's printed is an address within gdb's address space, that of the python object wrapping the gdb frame information.

I did deliberately model the FakeRepr representation on the output of PyObject_Repr when tp_repr is NULL:
   PyString_FromFormat("<%s object at %p>", Py_TYPE(v)->tp_name, v);
adding the "remote" word to disambiguate things.

Is that OK?  It seemed to me like the best compromise of readability and lack of ambiguity.


I'm attaching an updated version of the patch (version 3), and am about to attach a diff against the last version (which was version 2)

There are some other substantial changes in the patch:
- Line numbers reported in frames were incorrect; I've fixed this, mimicking the "dis" module/PyCode_Addr2Line
- I've started to add various "py-" commands (with selftests):
  - "py-list" command, which tries to mimic gdb's "list" command, but at the level of Python source code
  - "py-up" and "py-down" command, which go up and down the stack, based on the location of PyEval_EvalFrameEx frames
  - "py-bt" which prints a python-level backtrace, based on the location of PyEval_EvalFrameEx frames
- I added a trivial script (Lib/test/test_gdb_sample.py) for use by the test cases for the above
- Fixed a bug in PyStringObjectPtr.proxyval() so that it now supports strings with embedded NUL characters
- Various comment fixes.

I split out the test cases into multiple classes, invoking them all.  All pass on my system, taking under 20 seconds ("Ran 28 tests in 17.770s")