Hey Paul,
On 9 November 2010 16:59, Connell, Paul <[email protected]> wrote:
> Hi
>
> I have been playing with Cython gdb on Windows and finding it far from
> straightforward, as is often the case with *nix centric software. So here are
> my experiences, and I wonder if anyone else has had better or at least
> different experiences.
>
> The only gdb I was able to find with Python support is the one with
> Mingw/MSys. I had tried to build my own, but with no success as far as python
> support is concerned. I may revisit this at some point.
I don't have any experience with building gdb on windows, so I can't
really help in that regard. What I can say is, if your program is
compatible with Cygwin you could try to use gdb from there.
> The first problem I encountered upon running cygdb.py was, predictably, a
> posix-vs-windows path issue. I was able to kludge around this by hacking
> cygdb.py:
>
> import posixpath
> #...
> pattern = posixpath.join(path_to_debug_info,
> 'cython_debug/cython_debug_info_*')
> debug_files = glob.glob(pattern)
> new_debug_files=[]
> for df in debug_files:
> new_debug_files.append(string.replace(df, "\\", "/"))
> debug_files = new_debug_files
> if not debug_files:
> usage()
> sys.exit('No debug files were found in %s. Aborting.' % (
> os.path.abspath(path_to_debug_info)))
>
>
> otherwise cygdb tries to load e.g. .cython_debugcython_debug_info_mymodule as
> all the backslashes have vanished.
Regarding the path issue, I guess the code should have read
'os.path.join(path_to_debug_info, "cython_debug",
"cython_debug_info_*")'. I will try to fix and test it later today or
early tomorrow.
> The next problem was with the xml parser. I found I had to manually add
>
> from xml.parsers import expat
>
Why did you have to do that? I don't believe xml.parsers.expat
provides an ElementTree interface, so this would break all the code.
Cygdb needs an ElementTree implementation, of which there are several,
and it tries all implementations that are out there. Python2.5 comes
with xml.etree.ElementTree in the stdlib, and cygdb actually requires
python 2.5 or higher at this moment so it should not be an issue.
> cygdb now goes through the motions of working, although I am against another
> brick wall now in that my modules and python installation are all 64 bit,
> whereas mingw/msys is 32 bit. This isn't cygdb's fault though...
>
> I hope some of this is useful. I've not yet got a useable cygdb, but
> hopefully am getting there.
Yes, this is kind of unfortunate that windows is always a problem.
However, note that the cygdb tool is by no means needed to use the
Cython debugger. You can also start gdb manually, and issue the
command 'python from Cython.Debugger import libcython' and then import
the debug information with the 'cy import' command. Of course, cygdb
should and will be fixed, but it basically requires a sane
environment: gdb 7.2, python 2.5 and a compatible C compiler.
> Paul
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
>
Kind regards,
Mark
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
