Unfortunately, that is a significant chunk of work all the way from LLVM to LLDB. Currently, LLDB is unable to even unwind a basic stack. We need a replacement for DIA (PDB parsing), fixes for the ABI handling (something which is being looked into), dealing with .pdata
/.xdata
decoding and handling, dealing with mixed-debug info formats (sorry, but, PDB is not only better than DWARF but is also the native debugging format and for most of the cases that will still give better behaviour as well as be required for the system interleaving), dealing with mixed plan unwind (we do not always have debug info for everything), as well as significant work to shore up DWARF itself (DWARF with PE/COFF does not currently work well enough to actually describe the code on the platforms. Expression evaluation is pretty shoddy (heck, it didn't really function for anything beyond value printing really until I fixed the JIT). Finally, the question of how do you integrate with other IDE and debuggers remain: primarily, Visual Studio's debugger is much easier to work with, so that needs to be examined as well. All of this will still yield a sub-par experience as we didn't cover the nice to haves: stack analysis, exception analysis, caching of debug info, auto-fetching of PDBs from debug servers, auto-resolution of public and private PDBs, NatVIZ support, etc.
Oh, another thing that comes to mind is the fact that lldb's architecture causes a significant amount of pain for many environments: e.g. lldb-server
(DebugServer
in Xcode) is ~200x size of other debug servers (yes, there is a SR that I filed for that along with some work that has been committed upstream to help things) because suddenly everything in the compiler is dragged on to the target for a TCP server. Yes, this matters, because with Visual Studio (and VSCode) remote debugging is now totally possible for Windows, Linux, and android hosts.
I think that at least getting the REPL working is a huge step forward and will help the adoption of Swift, but, there are still large issues that need to be addressed in lldb. I am personally more interested in the compiler side of the project, but may delve into some of the problems I run into.
Sorry if the post seems overly harsh, but, the state of lldb just not great on most targets in my experience. It is not just a complaint - I have worked on lldb a bit in the past, as well as worked on LLVM to support lldb as well, so, I am not just being critical and complaining that it doesn't work for me - I have tried to improve things, but there tends to be a lot of push back for even simple improvements - e.g. unifying everything to a single build system. I brought up the point of code style in the past and that was effectively shut down saying that it works for the developers even though it makes it harder for those working on the related infrastructure to jump in.