On 3 November 2010 17:57, Robert Bradshaw <[email protected]>wrote:
> On Wed, Nov 3, 2010 at 2:55 AM, mark florisson > <[email protected]> wrote: > > Most of the Cython debugger is implemented, it can be pulled from > > hg.cython.org/cython-gdb. > > Cool! Have you recently pulled from main? Nope, I can try to pull and merge though if you want. > > 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. > > How much overhead (runtime, codesize, extra files, etc.) does > compiling with this option incur? Too much to enable by default? It writes debug information to the 'cython_debug' subdirectory of the build directory (so build_ext --inplace --pyrex-debug makes for a good combination of command line options to setup.py). It outputs information in XML so it needs an etree implementation (either from the xml.etree package, or from lxml or the regular elementtree package). I believe xml.etree.ElementTree is new in python 2.5. In any case, I don't notice any difference in time when compiling with debug information, but it's xml and it has to list the association between C line numbers and Cython line numbers. A quick test for a project which generates 8M of C code and ELF binaries has about 1M of debug information. So I'd say it's not really a bottleneck. > > 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. > > I'm not a gdb expert, but I definitely want to try this out. > Documentation would be great--either as a wiki or, preferably, the > main documentation (with a little note mentioning it's pending > release). I've given you push access to > http://hg.cython.org/cython-docs Great! I'll get on it next week. > > 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 > > > > > _______________________________________________ > 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
