[lldb-dev] post-mortem debugging with lldb

[Colin Riley]

Just to quickly butt in;

The lldb-mi driver can be found in tools/lldb-mi and at works with 
eclipse debugging remote hosts. There are a few contributing to it now, 
so hopefully more features are incoming.

Colin

On 01/12/2014 10:10, René J.V. Bertin wrote:
> On Sunday November 30 2014 18:00:11 Jason Molenda wrote:
>
> Hi,
>
> Nice to find someone so helpful on a list. Wish that was the case more often (looking at ya, KDE ;) )
>
>> Sorry, head, top of tree, tip of tree.  The trunk branch in svn.
> Thanks - I had understood the intent, just not the wording :)
>
>> When I looked at this yesterday I didn't see an obvious way to attach to a process without having a Target -- and couldn't create a Target without an executable file.  I need to go look at the API again but it wasn't super clear how to get started on your workflow where you're attaching to a PID.
> As I said, no hurry, but I appreciate the effort. BTW, DrKonqi does start *gdb* with both a pid and a the path to the executable, so that info could easily be provided to lldb too. I'm guessing you cannot really do without a pid for doing post-mortem debugging ...
>
>> Emulating the full gdb command line input/output would be a lot of work to make it behave 100% the same.  And some things would be very difficult to make the same -- for instance, gdb has a hand-written C/C++ parser to do expression evaluation (p 5+3).  lldb uses clang to do this - which means we behave more faithfully to the language spec but some things that aren't legal C/C++ are very useful to do in a debugger.  e.g. "p main + 5".
> You're right, there is also the issue of the output which is quite different.
>
> And as to output: DrKonqi only does some semi-clever parsing of the backtrace to determine to potential interest of the backtrace for bug reporting and AFAIK that only serves to prevent (disable) the wizard from creating reports with pointless backtraces. At the moment that's just shortcut to a 2-out-of-3 rating. It's not like there are hordes of people using KDE on OS X (or other hypothetical platforms that have lldb but not gdb) and generating bug report after bug report so there's pressure to implement a perfect parser :)
>
>> I think adding an MI interface for lldb is a good idea -- but trying to emulate gdb's command line behavior would be a huge time sink for little benefit.
> The little I've seen of it (getting kdevelop's debugger tool to function on OS X) the MI interface is a sort of superset of the regular command language, with additional information in the output. It's certainly true that the command line arguments can easily mapped in a shell wrapper, as far as they can be mapped.
>
>> (For an IDE, even better than using the MI interface would be to use lldb's native SB APIs to drive it.  It's a much cleaner and richer interface between the debugger library and the front end.  Hopefully some day we'll see the big IDEs like Eclipse use lldb by the SB API but until then, the MI is the easiest way to get them to work together)
> Somewhere on my todo list is the interfacing of kdevelop with lldb, but it can be very useful to have a dedicated GUI frontend, something that's not embedded in a big and heavy IDE. Qt-based, preferably, to make it as cross-platform as possible. I probably don't have to tell you that there are still many people who hardly use IDEs at all ;)
>
> R.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

-- 
- Colin Riley
Games Technology Director

Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.
Company registered in England and Wales, number: 04567874
Registered office: 81 Linkfield Street, Redhill RH1 6BY