[lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB
Leonard Mosescu via lldb-dev
lldb-dev at lists.llvm.org
Tue Nov 20 09:45:17 PST 2018
Not strictly related to LLDB but you might find this interesting:
On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> 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
> 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.croitor at qt.io>
> > 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 <jingham at 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 at 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 at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev