Lldb can't find existing pcm file on windows

Development Windows
, ,
1 
platform: windows 11
swift --version
compnerd.org Swift version 5.8 (swift-5.8-RELEASE)
Target: x86_64-unknown-windows-msvc

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.

@compnerd

*Edit update:
I redid the installation process, but following this guide instead: swift-setup/platforms/windows at main · pwsacademy/swift-setup · GitHub

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.

*Update 2:

I'm not sure why, but on my SDL project it crashes with:
Debug adapter exit code=3221225477 (0xc0000005), signal=null

When hitting a breakpoint.

2

I figured out a solution. For some reason, this error doesn't happen if I set the console key to internalConsole in launch.json for vscode.

{
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "sourceLanguages": [
                "swift"
            ],
            "name": "Debug SDLDemo",
            "program": "${workspaceFolder:SDL}\\.build/debug/SDLDemo",
            "args": [],
            "cwd": "${workspaceFolder:SDL}",
            "preLaunchTask": "swift: Build Debug SDLDemo",
            "console": "internalConsole"
        }
    ]
}
3

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.

1 Like
4

Ah ok thanks for the information. I'm just happy to get it 90% working lol (some path parameters don't resolve in the debugger).

I'll probably start moving over to the development snapshots soon.

5

Sorry about the delay, I forgot to post a response here. So, I did take a look into this problem. It is endemic to LLDB - it simply does not know how to interact with COFF files. I did address that problem upstream: ObjectFile: introduce a COFF object file plugin · llvm/llvm-project@5014830 · GitHub

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

Thanks for reporting the issue!

1 Like