Comming Soon to a Terminal Near You: Swift REPL on Windows

I was recently playing around with lldb, Swift, and Windows (as one does :-p). I have gotten the REPL to the point where it now runs on Windows! There are some improvements to be made still, primarily in the application of Data Formatters. However, the expression evaluation appears to work now and overall. If there are people who would like to get involved in the Windows port on the lldb side - this provides an excellent opportunity to delve into lldb. It also can expand easily into the compiler side if you start looking at the AST side of things.

Since people do love pictures, here is one of the repl in action (replete with some of the problems I mentioned):

Instructions for building this are already on the WindowsBuild entry, so feel free to explore :slight_smile:

CC: @dcci @Adrian_Prantl @Frederic_Riss @JDevlieghere

31 Likes

Awesome to see this coming along!
Were you able to figure out where the formatter for Array failed?
I don't have a Windows machine but should be able to provide some guidance if you have a debug session and see where the formatter is failing to match.

No, unfortunately, I wasn't able to track that down. Seems that the child handling is incorrect (there is no call made to FormatManager::GetSyntheticChildren on Windows).

sigh I cannot read nor follow instructions that I wrote. Sorry, I'll just see myself out the door.

image

2 Likes

Cool!

Cool! How much work does lldb on Windows need before we can remove -gdwarf-types from IRGen?

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.

2 Likes
Terms of Service

Privacy Policy

Cookie Policy