[issue10566] gdb debugging support additions (Tools/gdb/libpython.py)

[Mark Florisson]

Mark Florisson <markflorisson88 at gmail.com> added the comment:

Indeed, I'm trying to make the code Python 2 and Python 3 (for the inferior) compatible, it's not really hard but indeed, the 'u' (Python 2) and 'b' (Python 3) stuff need special casing. Python 2 compatibility was also the reason why the PyIntObjectPtr class was merged back. I will make a patch that's compatible with both Python 2 and 3 (and without any "colorful" code :)) as this would be most preferably I think (even if it's shipped with Python 3, users might still want to use it for Python 2, and it's also easier for the Cython debugger which wants to be compatible with 2.5+).

As for the gdb version, I have tested with 7.1 (in which case the introduced commands won't work as they use stuff from the 7.2 API, in which case test_gdb.py also skips those tests) and 7.2. I agree that the functionality should be left out if it cannot work properly.

Indeed, the _LoggingState redirects logging to a file and then reads the output after the command returns, I've been using it successfully with big amounts of output and I don't think there should be a problem as redirection and pagination should be unrelated. The good thing about _LoggingState is that it actually captures *all* output (and it's fully reentrant), which the 'to_string' argument was not taking care of properly in 7.2 (it's fixed in the archer branch).

Indeed, gdb.get_selected_thread() is entirely broken in 7.2 (again, fixed in archer) but as you can see, it's not used (gdb.inferiors()[0] "works").

I'm currently looking into making stepping over faster and by extension stepping which we discussed earlier (I also discussed it with Tom Tromey previously). As you know, currently stepping over (and stepping) works with a "step-over loop" which might be turned into a "set a conditional breakpoint or watchpoint + continue" solution, which would mean a lot less context switches. I've not looked too serious into this matter, but I'll hope to get around to that soonish and I'll provide a new patch with all the corrections and improvements.
Another issue I'm fixing is the determination of the type of an arbitrary Python object, which was previously done with the Py_TPFLAGS_INT_SUBCLASS flags and friends. This is because they are new in 2.6 and I'd prefer to be 2.5 compatible (again, because I'm trying to keep the Cython debugger 2.5 compatible).

As for porting the gdb API to Python 3, I'm quite convinced that the API can be written in Cython, in which case it would mostly be a change in the build process rather than a serious code-refactoring issue. But I'll get around to that later...

Anyway, should I diff against the original libpython or against the original libpython + my previous diff?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________