Dave Malcolm <dmalc...@redhat.com> added the comment:
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")
----------
Added file:
http://bugs.python.org/file16525/add-gdb7-python-hooks-to-trunk-v3.patch
_______________________________________
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
