Not strictly related to LLDB but you might find this interesting: https://blogs.dropbox.com/tech/2018/11/crash-reporting-in-desktop-python-applications
On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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 >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
