Definition of needs to have GUI debugging on Windows

Development Windows
1

Hi there,

I'm currently evaluating Swift for my company and it is a great langage that fits the needs of what we are doing: game dev. There is one core issue that we can't overpass, it's GUI debugging. I have been trying for the last three days to get something to work under VSCode with CodeLLDB on Windows 10 but I have not been able to.

From my reading of github issues and this forum, it seems that it is not ready for prime time yet. However, I want to know what's required to have that working. Langages like Rust do use LLDB on windows without too much issues and PDB generation is working. On such basis, I'm wondering what should be fixed so that we get the same level of debugging as Linux and Mac on Windows?

Thank you.

Some information about my build :
CodeLLDB 1.8.1 for VSCode
Swift 5.7.3-RELEASE
Swift Server Work Group 1.0.0 for VSCode
Windows 10 version 19045.2486

Main issue :
Cannot create Swift scratch context windows 10 (CodeLLDB crashes when setting a breakpoint in VSCode or calling po from command line within LLDB).

I also see that there is no PDB generation (or so it seems) in the debug folder of my application.

1 Like
2

There is some very limited PDB generation that is supported but that requires that you are enabling it. For an example of that see compnerd/DXSample: Sample Program for DirectX 12 + Swift (github.com)

3

Thank you! This is going to help to understand a little bit better what to do.

Do you have any idea where to start to improve debugging info? A ticket, an issue, a start point?

So far, I'm able to see most struct and values from Fondation but not from my own code. Struct and classes simply crashes LLDB. If I can make a PR to help progress this, I would do it. Same for autocomplete, sourcekit-lsp is not able to return valid inputs and suggestions for my functions and classes/struct/types.

4

It depends on what you are looking for. I think that we will need to consider LLDB as the debugging tool rather than WInDBG/Visual Studio. At that point, rather than PDBs (which IMO are still important for profiling), we should consider the serialised data approach that the other platforms use. When we get to that, I think that the pieces to start looking at are LLDB, and there in particular is library path resolution so that LoadLibraryW is able to load swiftCore.dll into the address space to enable expression evaluation which is fundamental to how LLDB operates.

Once we have that, it will be a fork where we start to improve the PDB loading because the system frames are still going to be using PDBs and the rest will be DWARF augmentation for the Swift side. Getting that resolved and merged should give us a decent path to improved debugging including the VSCode integration.

Please try the latest snapshots, autocompletion should work OOTB when using SPM for your project.

5

It depends on what you are looking for. I think that we will need to consider LLDB as the debugging tool rather than WInDBG/Visual Studio.

Since I'm not used to Dwarf, it will take some time before I fully grasp that format and what to do, but I will try to push for it. Thank you!

Please try the latest snapshots, autocompletion should work OOTB when using SPM for your project.

Sadly, Swift extension breaks due to "swift error: toolchain is invalid: could not find link" which breaks building from VSCode directly and also break Sourcekit-LSP. I found the github related issue #5720 and related proposition for a fix.

I was able to run vscode from vs native cmd x64 and then I got it running in a good state. Even debugging is somewhat ok and LLDB is showing variables states in debugging. However, autocompletion is still not working.

Again thank you for your help, I will see how I can help to get this moving forward. It is a huge chunk, but I do believe it is worth the effort.

EDIT: still have some crashes with LLDB, needs to investigate. But local classes and struct are now visible in the debugger.

6

That path should be relatively well tested on non-Windows, so it will be more about picking off issues that we find as we start using that more. If you are familiar with CodeView, and can enhance the CodeView that we emit, that would be great!

7

So I'm still working on understanding what's has been done and what to do while I'm trying to build the toolchain. I have a few questions:

Is this the right instruction to build the toolchain on windows?

Currently, I can build llvm but trying to build swift fails due to :

CMake Error at cmake/modules/AddLLVM.cmake:764 (add_custom_target):
  add_custom_target cannot create target "install-swift-frontend" because
  another target with the same name already exists.  The existing target is a
  custom target created in source directory "S:/swift/tools/driver".  See
  documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:2100 (add_llvm_install_targets)
  S:/swift/cmake/modules/AddSwift.cmake:975 (llvm_install_symlink)
  S:/swift/tools/driver/CMakeLists.txt:113 (add_swift_tool_symlink)

Any idea what to do?

I think I will also update the doc because it was missing this as well

-D SWIFT_PATH_TO_SWIFT_SYNTAX_SOURCE=S:\swift-syntax ^

for CMake.

8

That is a bit out of date, but the general thing should be correct. I would suggest swift-build/WindowsQuickStart.md at main · compnerd/swift-build · GitHub as a reference which uses some different tooling, but I find to be easier and more reliable.

The errors are because you checked out the wrong version of LLVM BTW, not because of missing swift-syntax.

1 Like
9

I followed your build steps to a T. It went well until I falled on this issue. But I managed to get swift compiled and working, so I can start working on the next steps. I'm able to generate a valid executable from the swift.exe.

C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\include\dispatch\module.modulemap:1:8: error: redefinition of module 'Dispatch'
module Dispatch {
       ^
S:\SourceCache\swift-corelibs-libdispatch\dispatch\module.modulemap:1:8: note: previously defined here
module Dispatch {
       ^
C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\include\dispatch\module.modulemap:8:8: error: redefinition of module 'DispatchIntrospection'
module DispatchIntrospection [system] [extern_c] {
       ^
S:\SourceCache\swift-corelibs-libdispatch\dispatch\module.modulemap:8:8: note: previously defined here
module DispatchIntrospection [system] [extern_c] {
       ^
C:\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk\usr\include\dispatch\module.modulemap:13:8: error: redefinition of module 'CDispatch'
module CDispatch [system] [extern_c] {
       ^
S:\SourceCache\swift-corelibs-libdispatch\dispatch\module.modulemap:13:8: note: previously defined here
module CDispatch [system] [extern_c] {

I suppose I can add the two proposed options in the build.cmd file from the issue in the meantime or would you prefer to keep it as is? @compnerd

--skip-early-swift-driver \
--skip-early-swiftsyntax

Also, for anyone reading this thread in the future, you might need git LFS installed for ICU. I resolved a couple of warnings by installing it.

10

Those options are not applicable to the build.cmd, they are part of build-script which Windows does not use.

That is an artifact of Swift's build system. You cannot have an installation of Swift on the machine. Uninstall Swift, Visual Studio, clean up the file system, and then reinstall Visual Studio and you should be able to build.