Dave Malcolm <dmalc...@redhat.com> added the comment:
This is very interesting work - thank you!
Sorry for not commenting earlier (very busy), so here are my thoughts so far.
The baseline for the diff appears to be against the py3k branch, in that it
adds back in classes from 2.*: PyIntObject.
There's currently some deliberate divergence between the code in the 2.7 branch
and the py3k branch. For example, in the 2.7 branch, we pretty-print
PyUnicodeObject instances with a u'' prefix, whereas in the py3k branch we
pretty-print them plainly: the code is trying to mimic the underlying syntax of
a particular version of the python language in the inferior process. (In both
cases though, the gdb code is for python 2)
Are you attempting to support both python 2 and python 3 (in the inferior
process) from the same code?
Going through the individual parts of the patch:
Do the changes to "pretty_printer_lookup" slow things down, I wonder? (It has
to be called every time gdb print a pointer)
"py-globals" looks like a nice addition, though I feel there should be an
abstract base class for PyLocals and PyGlobals to inherit from
("PyNamespaceCommand", perhaps, though that sucks as a name).
The "py-break" command looks very useful Unfortunately, AIUI we're in feature
freeze for 3.2 now (sorry not to get to this earlier), and I have some fears
about compatibility with all of the different versions of gdb 7 that are out
there. What versions of gdb have you tested this with?
_LoggingState looks interesting; getting the various versions of gdb to capture
output as a python string can be challenging. In particular, I've run into
problems with buffering of large amounts of output; see:
https://bugzilla.redhat.com/show_bug.cgi?id=620930
get_selected_inferior() clearly is impacted by gdb bugs, so I'm warying about
merging that
Likewise for GenericCodeStepper.init_breakpoints (probably should refrain from
swearing in comments, if nothing else, it's a dead give away that the code
needs more work :) I don't know if we have any rules about it, but I don't
remember seeing such "colorful" language before in python's sources)
I notice that the selftests use skip_unless_7_2_decorator on the tests for
py-break, py-step, py-next and py-exec. If these commands only work on a
sufficiently recent version of gdb, should the commands themselves also be
wrapped in a conditional? Either not registering them if gdb doesn't have the
support, or perhaps registering a fallback that says "gdb not recent enough",
or somesuch. Part of gdb's UI is tab-completion, and it's nice for "py-[TAB]"
to present all useful options. That makes me think that we shouldn't register
commands that are known to be incompatible with the running gdb version.
This is exciting work, in that gdb seems to be getting significantly more
powerful, and the debug hooks are advancing to take advantage of it.
Unfortunately, given that Tools/gdb/libpython.py is part of the python source
tree, it's arguably governed by the same feature freeze rules as the rest of
Python (e.g. no new features in 2.7). I wonder if an exception can be made for
it, given that this code is a support tool that runs in a different process to
the main python build, potentially for a different major-release of python.
(At some point we'll want to port gdb to python 3, which I'm not looking
forward to...)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
