Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

2018-11-20 Thread Alexandru Croitor via lldb-dev 
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  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  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 
>>>  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

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

2018-11-20 Thread Leonard Mosescu via lldb-dev 
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 
> 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  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

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

2018-11-20 Thread Zachary Turner via lldb-dev 
On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
> 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.


Not sure how much it will help you, but on Windows if you're using MS
Visual Studio, their debugger does this.  You can seamlessly step between
managed and native code and see Python callstacks interspersed with  native
callstacks.  It's all open source but it's quite a lot of code to dig
through, and unless you have a Windows machien, you won't be able to play
around with it anyway.

https://github.com/Microsoft/PTVS/tree/master/Python/Product
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

2018-11-20 Thread Alexandru Croitor via lldb-dev 
Thanks. That's useful info that covers the "squishing" of C frames into Python 
frames.

The link to the slides at the end also mentions two other useful projects for 
walking the stack, py-spy and pyflame.

Having said that, I'm more interested on the "lldb" side of things.

On 20. Nov 2018, at 18:45, Leonard Mosescu 
mailto:mose...@google.com>> wrote:

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 
mailto: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 
> mailto: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 
>> mailto: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 
>>> mailto: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

Re: [lldb-dev] Debugging Python scripts (backtraces, variables) with LLDB

2018-11-20 Thread Alexandru Croitor via lldb-dev 
Thanks for the link. I'm aware that VS provides that functionality (although I 
forgot that it was open-source).

My aim would be to implement something similar in LLDB though.


On 20. Nov 2018, at 18:49, Zachary Turner 
mailto:ztur...@google.com>> wrote:



On Tue, Nov 20, 2018 at 8:51 AM Alexandru Croitor via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

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.

Not sure how much it will help you, but on Windows if you're using MS Visual 
Studio, their debugger does this.  You can seamlessly step between managed and 
native code and see Python callstacks interspersed with  native callstacks.  
It's all open source but it's quite a lot of code to dig through, and unless 
you have a Windows machien, you won't be able to play around with it anyway.

https://github.com/Microsoft/PTVS/tree/master/Python/Product

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 39727] New: Support for breakpad symbols in LLDB

2018-11-20 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=39727

Bug ID: 39727
   Summary: Support for breakpad symbols in LLDB
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: enhancement
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: d...@google.com
CC: llvm-b...@lists.llvm.org, mose...@google.com

LLDB should be able to consume breakpad symbols.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev