platform: windows 11
compnerd.org Swift version 5.8 (swift-5.8-RELEASE)
I was able to successfully set up the swift sdk toolchain on windows following the instructs on swift.org.
However, getting the debugger to work with vscode + codelldb has been troublesome.
Some things to get it to work this far:
set this path in settings.json : "lldb.library": "c:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\liblldb.dll"
download python 3.10 and add the .dlls to the path above
Now the debugger sort of works, but on hitting a breakpoint it fails to resolve a few module paths:
Cannot create Swift scratch context (couldn't load the Swift stdlib)warning: (x86_64) C:\Users\Isaac\Documents\Projects\swift\SDL\.build\debug\SDLDemo.exe 0x00000478: unable to locate module needed for external types: C:\Users\Isaac\Documents\Projects\swift\SDL\.build\x86_64-unknown-windows-msvc\debug\ModuleCache\29SSNJPN28VQD\SDL2-2BXSUYAOGGNQ7.pcm
error: 'C:\Users\Isaac\Documents\Projects\swift\SDL\.build\x86_64-unknown-windows-msvc\debug\ModuleCache\29SSNJPN28VQD\SDL2-2BXSUYAOGGNQ7.pcm' does not exist
Debugging will be degraded due to missing types. Rebuilding the project will regenerate the needed module files.
These modules definitely exist at the path reported.
I looked at the lldb source and GetModule calls FileSytem::Exists(..) which forwards calls to a vfs::FileSystem . It seems that the exists() function is failing. I have yet to pinpoint exactly why. Either way, I wanted to make a bug report though issues can't be created on github?.. so hence this post.
The debugger works much better and no longer crashes. (Maybe because I only had the windows 11 sdk instead instead of windows 10?) However, the debugger still fails to show any variables for tied to SDL, and the same errors appear despite the pcm files existing.
I'm not sure why, but on my SDL project it crashes with:
Debug adapter exit code=3221225477 (0xc0000005), signal=null
The error that you are seeing 0xc0000005 is indicative of a breakpoint failure (its an access denied, which means that the software breakpoint either failed to be written or mutated on trigger).
As to the PCM issue, that is still a problem. I've been working on improving the LLDB experience, but there is still work to be done. If you like to use LLDB, I would highly recommend that you use the main development snapshots as things are evolving pretty rapidly.
I've intentionally not yet backported the change as this will break debugging once again. It results in an assertion failure at:
due to the imported type of PVOID which is a typealias for UnsafeMutableRawPointer from WinSDK. I've only seen it on that particular type, though it is possible that it has broader implications. I think that we might be able to paper over the issue for the time being by just adding PVOID to the special known types as we do with NSNotification. Once we have a known path forward, I should be able to downstream the change and resolve this issue.
This does make a significant impact on debugging as many types become significantly easier to debug due to po becoming more usable (at least for non-SDK/non-foreign types).