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
