Hi Pablo, On 19/01/2021 6:46 pm, Pablo Galindo Salgado wrote:
Hi Mark,
Thanks for gathering this proposal! Looks very interesting. I have some preliminary questions: how is this going to affect the "py-bt" command of the gdb helpers (https://github.com/python/cpython/blob/master/Tools/gdb/libpython.py#L1876-L...) and other similar tools that produce a unified Python-C backtrace? There are several debuggers that rely on the fact that they can merge the C stack and the Python stack by substituting every call to "_PyEval_EvalFrameDefault" and friends for the respective Python frame obtained separately or by inspecting the frame object in the stack (like gdb does).
I don't see any problem fixing up the gdb helpers. The code will need to be aware that C frames will be one-to-many to Python frames, but there's nothing tricky there.
Is this change going to affect these tools or they will continue working as before? In case this change will affect this tools, is there any workaround to produce the unified C/Python call stack given the Python stack and the C stack?
It depends on what you mean by "similar tools". For in-process tools, then the API will continue to work. For out-of-process debuggers, then the author's are on their own. But that's always been the case. The source code is public, and it won't be any more opaque than it is at the moment :) Cheers, Mark.
Kind regards, Pablo Galindo Salgado _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/27DON4D7... Code of Conduct: http://python.org/psf/codeofconduct/