I'd also like to mention that cygdb is a lot more useful when using a python debug build (or having compiled python with -g). Of course, extensions should also be build with -g, which is the default I believe.
On 3 November 2010 10:55, mark florisson <[email protected]> wrote: > Most of the Cython debugger is implemented, it can be pulled from > hg.cython.org/cython-gdb. To use it, you need Cython to export some debug > information, which can be done using 'cython --debug mymod.pyx', or 'python > setup.py build_ext --pyrex-debug'. You can also pass 'pyrex_debug=True' as > an argument to Cython.Distutils.extension.Extension. > You can then start gdb by typing 'cygdb' (which should be installed as a > script) in your project directory. Then 'help cy' gives an overview of > commands. It currently supports breapoints, stepping, stepping-over, > backtraces, source code listing, going up and down the stack, printing > variables with regard to context, listing locals or globals and running and > continuing the program. If pygments is installed it will colorize source > code which is configurable through cy_* parameters. > > It basically works on three levels: the Python, Cython and C level. > Depending on the context cygdb does the right thing. For stepping it > considers the following stack frames relevant: any Python frame, any Cython > frame and any C frame from a C function called directly by Cython user-code. > > So, it would be great if some people could test and try it (unit tests are > written but some system testing is always great). It works with gdb 7.2 (the > 7.1 python api was too incomplete and broken). So if you guys like it I > could write documentation that explains to Cython users how to install and > use it. Any suggestion or criticism is most welcome! > > The Python support (libpython.py) was also modified. I'd like to push this > mainstream (and process any suggestions and criticism) before supplying a > patch to Python. > > Kind regards, > > Mark > > > On 15 September 2010 17:49, Robert Bradshaw > <[email protected]>wrote: > >> On Wed, Sep 15, 2010 at 2:55 AM, mark florisson >> <[email protected]> wrote: >> >> >> It ought to be possible to do something similar with cython code. It >> >> may not even be necessary to modify cython: perhaps some searching for >> >> locals named "__pyx_*" iirc would get you 70% of the way there? >> > >> > Although that sounds like a wonderful idea, I think there are also >> > issues with that. One issue is that a user must be able to set Cython >> > breakpoints before the Cython module would be loaded, and for that the >> > symbol name would be needed beforehand. Also, I don't know if these >> > mangled names are consistent now and in the future and if you would be >> > able to unambiguously associate a Cython variable name with a mangled >> > name. >> >> Mangled names are deterministic and, though they're not guaranteed to >> be consistent from release to release, almost always are. >> >> >> I can attest that having the prettyprinters enabled does make it much >> >> easier to debug cython code: all of the PyObject* get prettyprinted. >> > >> > I've been looking at the code and this is pretty neat. I did encounter >> > some issues, for instance if you load the script before loading the >> > python interpreter you get this traceback because these types are not >> > defined at that time: >> > >> > Traceback (most recent call last): >> > File "<string>", line 1, in <module> >> > File ".libpython.py", line 49, in <module> >> > _type_size_t = gdb.lookup_type('size_t') >> > RuntimeError: No type named size_t. >> > >> > So I think it would be a good idea to not make that code module-level. >> > >> >> >> >> One other thought: if it's possibly to expose the cython structures in >> >> some meaningful way, perhaps we could change upstream python's gdb >> hooks >> >> to simply integrate them into the py-* commands I mentioned above? (so >> >> e.g. cython c functions get somehow treated as python frames; currently >> >> I have a test predicate: >> >> Frame.is_evalframeex() >> >> which perhaps could be generalized?) >> >> >> >> (Not sure; it would complicate the selftests within python itself) >> >> >> > >> > I think it would be hard to make them actual Python frames because >> > creating frames in the inferior process from gdb is probably quite >> > dangerous, and the alternative would be to modify Cython so that it >> > creates Python stack frames (this sounds feasible but I think it might >> > be a little bit of work). However, if this could be done (it would >> > only do so if this 'debug' flag is active), then tracebacks and locals >> > inspection etc wouldn't need special attention and the code would >> > appear as normal Python code (apart from the Code objects obviously). >> > However, this would form a problem for non-primitive C-type Cython >> > variables. >> > >> > So at the very least we could have a 'py-locals' or some such command >> > that would show the value of all the locals (the Python locals would >> > be printed by py-print and C locals by gdb print). For regular python >> > code it would show the locals from the current stack frame. For the >> > Cython part to work we would need information from the Cython compiler >> > because we wouldn't want to list any temporary or irrelevant >> > variables. >> >> Yes, this is what I was thinking, at least in terms of exposing stuff >> to pdb (which is a complementary project). BTW, frames are already >> created for functions when profiling is enabled. >> >> > So I think we should be able to integrate these two projects into one >> > fruitful project, and with proper documentation it could help both >> > regular Python users and Cython users. >> >> +1 >> >> - Robert >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > >
_______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
