Hello, It's been a while since I asked this question on the mailing list ( 2~ years ago).
I am interested in what would be the current best way for implementing interleaved / mixed-mode Python backtraces when debugging the CPython interpreter. So if I run lldb -- python /path/to/my/script, set a breakpoint somewhere in the C code, and then do "bt", I would see a list of both C stack frames and Python stack frames, and if I do "frame select x" for a python frame, I could inspect the Python locals for instance. Last time I asked, Jim mentioned using a custom "thread provider". Would this still be the way to go? I also saw mentions of Java / Go support in the VCS log, but the support was removed due to no maintainers, so I don't know if that would also be the best way of doing it for Python. I would appreciate, if someone could point me to some relevant code that does something similar to what I'm asking, so I could use it as a base point for exploration. Many thanks. > On 8. Jul 2016, at 12:24, Alexandru Croitor <alexandru.croi...@qt.io> wrote: > > Thanks for replying, it's good to know what the status is at least, as well > as how it's done in GDB. > >> On 06 Jul 2016, at 20:56, Jim Ingham <jing...@apple.com> wrote: >> >> Nothing of this sort has been done to my knowledge, and I haven't heard of >> any plans to do so either. >> >> It should certainly be possible, you just need to grub the C stack and >> recognize the pattern of a Python stack frame in it and where said frame >> stashes away the arguments & locals, and then re-present it as a Python >> frame. The SB API's should make that fairly straight forward. >> >> It looks like the Python work in gdb is based on a generic "frame filter" >> concept in the gdb Python API's. That's something Greg and I talked about >> when working on gdb way back, and has been a future goal for lldb from the >> start, but it hasn't ever gotten beyond discussion to date. We already have >> the notion of a "thread provider" which allows the Mach Kernel plugin to >> present its activations as threads in lldb. You could do much the same >> thing in lldb, where a thread would have the native unwind based stack frame >> and then pluggable StackFrame provider that would show different >> representations of the stack. >> >> If anybody is interested in taking on such a project, that would be very >> cool. >> >> Jim >> >>> On Jul 6, 2016, at 8:48 AM, Alexandru Croitor via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> >>> Hello, >>> >>> I've searched for information wether it is possible to debug a python >>> script using LLDB, and haven't found anything so far. >>> >>> Specifically I'm interested in an LLDB counterpart to what GDB provides >>> (the two main pages being https://wiki.python.org/moin/DebuggingWithGdb and >>> http://fedoraproject.org/wiki/Features/EasierPythonDebugging ). >>> >>> So python stack traces, python values, etc. >>> >>> I assume this is not implemented, but are there any plans, or is it even >>> feasible to implement? >>> >>> Regards, Alex. >>> _______________________________________________ >>> lldb-dev mailing list >>> lldb-dev@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
