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
