Trying to diagnose a crash that's always on a call into memcpy() from an audio thread. I've figured out how to generate memory dumps when my program crashes, but the dumps aren't useful because there are no symbols I can see when I open the .dmp files in Visual Studio. Is there a way to build Swift code on Windows such that standard debugging tools can give me a detailed stack trace? Are there swift build settings I need to enable? I believe my program is entirely statically linked. When I tried using .dynamic for the library targets, the program failed to link.
Static linking for Swift content is unsupported on Windows. The debugging is somewhat more challenging. If you are trying to debug the C side of the code, it should work really well - you should be able to add
-Xswiftc -g -Xswiftc -debug-info-format=codeview. If you are trying to debug the Swift side of the code, its a bit of a hit or miss. Due to the other changes (e.g. concurrency, etc) and the existing backlog (e.g. LSP, SPM, ...), I've not had time to look too deeply into the LLDB nor PDB generation for Swift. You can try the PDB approach with the same flags as above, but if that doesn't work, then you might have to do either try the DWARF path (which doesn't work very well on Windows in my experience) with LLDB or fall back to non-symbolic debugging.
When I build with .dynamic for my libraries, I get link errors in the downstream dependent targets. No symbols are found. My case may be unusual. I’m building C libraries using SPM without any specific linker flags. Do I need to pass any linker flags to get the windows linker to export my C library’s symbols? Shouldn’t the DLLEXPORT directives be taking care of that? According to Microsoft documentation I can use a .def file or
__declspec(dllexport) directives should do the right thing. However, in the header, when not building the library, you need to decorate the symbols with
swift-cmake-examples/HelloWorld at main · compnerd/swift-cmake-examples (github.com) should give you a working example for this.
Yes, my libraries needed to have DLL_EXPORT defined. Now the .dynamic versions are working.