This project has moved. For the latest updates, please go here.

Mixed-Mode debugging using python 2.5

Oct 29, 2013 at 9:20 PM

I am trying to debug using mixed-mode with python 2.5. I have the symbol file for python 2.5 but it does not hit my python break point saying "No symbols have been loaded for this document." Will mixed mode not work at all with python 2.5 even if the symbols are loaded?


'python.exe' (Win32): Loaded 'C:\Python25\python.exe'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\SysWOW64\python25.dll'. Symbols loaded.
Oct 29, 2013 at 9:27 PM
Edited Oct 29, 2013 at 9:28 PM
In PTVS 2.0, mixed-mode debugging is only supported for Python 2.7.x and Python 3.3.x. Future releases will add support for new 2.7.x point releases, as well as any new 3.x versions, but we don't have plans to support 2.5 or 2.6 at the moment.

Unfortunately, we can't easily support arbitrary Python versions, because the nature of mixed-mode debugger requires it to work directly with internal Python data structures, which can and do change from version to version, so adding any new version to the supported list is an expensive proposition.
Oct 29, 2013 at 9:32 PM
Is it possible for me to add support for python 2.5. I have been dabbing around in ver 1.5, adding zip support for it. If possible can you point me in the detection to get started?
Oct 29, 2013 at 10:06 PM
I haven't looked into how difficult it would be - this is basically directly proportional to the amount of internal differences - but it should certainly be possible, following the existing patterns that deal with 2.7/3.3 differences.

All code related to mixed-mode debugging is here:

"Entry point" classes are RemoteComponent.cs, LocalComponent.cs and LocalStackWalkingComponent.cs; this is what the VS debugger infrastrucure calls, and they mostly just call out to other, area-specific classes like TraceManager or ExpressionEvaluator.

For version detection specifically, look at PythonDLLs.GetPythonLanguageVersion and its callers.

Most of the changes would probably be in handling of data structures like PyObject-derived structs. Those have proxy objects representing them in the debugger - those proxies live in PyCodeObject and PySetObject would be good starting points to see how those are authored. Some existing examples of proxies that differ depending on Python versions are PyDictObject and PyUnicodeObject. But, basically, you'd have to go through all those proxies and see if the corresponding struct definition in Python header files is different between 2.5 and 2.7 (note that field ordering doesn't matter - it's only when types are different or the entire structure is different that you need to have separate proxies).

A few other places where breakage might occur on a different version is where we set breakpoints inside Python internal functions, or read/write static variables. Things to look for are methods marked with [StepInGate] attribute, and calls to GetStaticVariable, GetExportedFunctionAddress, GetExportedStaticVariable, CreateRuntimeDllFunctionBreakpoint and CreateRuntimeDllFunctionExitBreakpoints.

I'll be happy to help with any further questions about that code, so feel free to ask.
Oct 29, 2013 at 10:22 PM
Thanks allot, this will get me started.