IDE Support for LLDB on Windows

[RussellHaley]

This issue is to outline the methods of using llvm-mingw/lldb with the various IDEs on Windows.

• Eclipse - lldb-mi
• VS Code - lldb-mi, lldb-vscode
• KDevelop
• Qt Creator
• CLion
• Code Blocks
• ?

Other questions:

• Where is the best place to put this information? Should this be turned into a wiki?

@longnguyen2004 has graciously volunteered to fill in the items that he has tested.

[longnguyen2004]

First, answering some questions:

I think adding python 2 support would be largely trivial at this point

Yes it would be pretty trivial, but maintaining 2 different versions of Python is gonna be a pretty big burden, given that Python 2 might even need more patching. I think we should only have Python 3 for now, as it's the preferred version on other toolchains (mingw-builds and TDM-GCC come to mind).

are you using a plugin? Could you share your launch configuration?

I use the C/C++ extension on Visual Studio Code, and the LLDB Debugger Integration on Eclipse (detailed guide will come soon)

Ok, so would including lldb-vscode be useful (as it's trivial to do)?

I think keeping lldb-mi would be more useful, since lldb-vscode is intended to be packaged up as an extension for IDEs, instead of being used standalone like lldb-mi.

[longnguyen2004]

Eclipse

1. Install the LLVM and LLDB support software

• Go to Help -> Install New Software
• Select the CDT site, and install "C/C++ LLVM-Family Compiler Build Support" and "C/C++ LLDB Debugger Integration (experimental)" in "CDT Optional Features"

2. Setup the compiler

• Go to Project -> Properties
• Go to C/C++ Build -> Tool Chain Editor
• Change the current toolchain to LLVM with Clang (Windows) (MinGW) (You might need to uncheck "Display compatible toolchains only")

3. Setup the debugger

• Go to Run -> Debug Configurations
• Select C/C++ Application, then click "New Configuration" in the corner
• Click "Select other" at the bottom, then select "LLDB-MI Debug Process Launcher"
• Change the "C/C++ Application" field to the path of your program.
• Go to the Debugger tab, and change the LLDB command to the path of lldb-mi. Optionally, uncheck "Stop on startup at" to prevent LLDB from breaking at the start of main

Happy debugging!

[RussellHaley]

First, answering some questions:

I think adding python 2 support would be largely trivial at this point

Yes it would be pretty trivial, but maintaining 2 different versions of Python is gonna be a pretty big burden, given that Python 2 might even need more patching. I think we should only have Python 3 for now, as it's the preferred version on other toolchains (mingw-builds and TDM-GCC come to mind).

I'm not bothered either way as I can add the support myself if needs be. KDevelop does not seem to work with Python 3. My goal is to support KDevelop.

are you using a plugin? Could you share your launch configuration?

I use the C/C++ extension on Visual Studio Code, and the LLDB Debugger Integration on Eclipse (detailed guide will come soon)

Ok, so would including lldb-vscode be useful (as it's trivial to do)?

I think keeping lldb-mi would be more useful, since lldb-vscode is intended to be packaged up as an extension for IDEs, instead of being used standalone like lldb-mi.

Sorry I was unclear: I agree with you.

[longnguyen2004]

Visual Studio Code

• Prerequisite: The C/C++ extension (use this link or search for C/C++ in Visual Studio Code)

1. Setup the compiler

• Go to File -> Open Folder and open a folder of your choice
• Create a new folder named .vscode (note the dot)
• Inside the .vscode folder, create a file c_cpp_properties.json
• Paste the following in the file

{
    "configurations": [
        {
            "name": "llvm-mingw",
            "includePath": [
                "${workspaceFolder}/**",
            ],
            "defines": [
                "_DEBUG"
            ],
            "compilerPath": "<path to toolchain>/bin/clang-<version>.exe",
            "cStandard": "c17",
            "cppStandard": "c++17",
            "intelliSenseMode": "windows-clang-x64",
            "compilerArgs": [
                "-glldb",
                "-lc++",
                "-lunwind",
            ]
        }
    ]
}

Replace <path to toolchain> and <version> with the appropriate values

2. Setup the debugger

• In the .vscode folder, create a file launch.json
• From here, you have 2 options:

A. lldb-mi + C/C++ extension (NOT RECOMMENDED, see below)

• Paste the following into the file

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb-mi) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "MIMode": "lldb",
            "miDebuggerPath": "<path to lldb-mi>",
            "preLaunchTask": "C/C++: clang-<version>.exe build active file",
        }
    ]
}

Replace <path to lldb-mi> and <version> with the appropriate values.

Drawbacks of this method: "externalConsole": true doesn't work (it does open a console, but stdout isn't redirected to the console, and instead go through VSCode's debug console). As such, there's no way to input through stdin.

B. The CodeLLDB extension

• Install the CodeLLDB extension (use this link or search for CodeLLDB in Visual Studio Code)
• Paste the following into launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(CodeLLDB) Launch",
            "type": "lldb",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "cwd": "${fileDirname}",
            "terminal": "external",
            "preLaunchTask": "C/C++: clang-<version>.exe build active file",
        }
    ]
}

Replace <version> with the appropriate value Note: This extension uses its own build of LLDB

[longnguyen2004]

Code::Blocks

Not supported :( (Compiler only, debugger not supported)

[RussellHaley]

Visual Studio Code

• Prerequisite: The C/C++ extension (use this link or search for C/C++ in Visual Studio Code)

1. Setup the compiler

• Go to File -> Open Folder and open a folder of your choice
• Create a new folder named .vscode (note the dot)
• Inside the .vscode folder, create a file c_cpp_properties.json
• Paste the following in the file

{
    "configurations": [
        {
            "name": "llvm-mingw",
            "includePath": [
                "${workspaceFolder}/**",
            ],
            "defines": [
                "_DEBUG"
            ],
            "compilerPath": "<path to toolchain>/bin/clang-<version>.exe",
            "cStandard": "c17",
            "cppStandard": "c++17",
            "intelliSenseMode": "windows-clang-x64",
            "compilerArgs": [
                "-glldb",
                "-lc++",
                "-lunwind",
            ]
        }
    ]
}

Replace <path to toolchain> and <version> with the appropriate values

2. Setup the debugger

• In the .vscode folder, create a file launch.json
• From here, you have 2 options:

A. lldb-mi + C/C++ extension (NOT RECOMMENDED, see below)

• Paste the following into the file

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb-mi) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "MIMode": "lldb",
            "miDebuggerPath": "<path to lldb-mi>",
            "preLaunchTask": "C/C++: clang-<version>.exe build active file",
        }
    ]
}

Replace <path to lldb-mi> and <version> with the appropriate values.

Drawbacks of this method: "externalConsole": true doesn't work (it does open a console, but stdout isn't redirected to the console, and instead go through VSCode's debug console). As such, there's no way to input through stdin.

B. The CodeLLDB extension

• Install the CodeLLDB extension (use this link or search for CodeLLDB in Visual Studio Code)
• Paste the following into launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(CodeLLDB) Launch",
            "type": "lldb",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}.exe",
            "args": [],
            "cwd": "${fileDirname}",
            "terminal": "external",
            "preLaunchTask": "C/C++: clang-<version>.exe build active file",
        }
    ]
}

Replace <version> with the appropriate value Note: This extension uses its own build of LLDB

Ha ha. I guess I can delete the VS Code notes that I didn't finish (sorry, swamped with work right now). I noted that the CodeLLDB is only a couple of megabytes in size (I forget, 20,40 MB?). I checked out their plugin and they have used just the libpython.dll, lldb and some support libraries and did not include the whole Python standard library. LLDBCode can be used with llvm-mingw without debuggers in our base bin directory; I tested this by removing all LLDB binaries from my installation and the debugger still worked.

[RussellHaley]

CLion doesn't want to play nicely; the standard way of adding a compiler (File->Settings->Build, Execution, Deployment->Toolchain) doesn't work. The recommendation is to install VS or to use the GNU toolchain and then force CMake to use a different compiler through a toolchain file or directly setting CMAKE_C_COMPILER.

There is an open issue and I submitted a comment mentioning this toolchain and my variant: https://youtrack.jetbrains.com/issue/CPP-10711#focus=Comments-27-4712333.0-0

[longnguyen2004]

Qt Creator won't let me save a configuration without a Qt installation. Can someone help me with that?

[RussellHaley]

Qt Creator won't let me save a configuration without a Qt installation. Can someone help me with that?

Sorry, just saw this.

How did you install QtCreator? Can you explain what configuration you can't save? I haven't tried debugging yet (and as usual, I have run out of time), but I can get QtCreator to build with llvm-mingw.

• I used the Qt installer and installed "just QtCreator" (I de-selected everything else).
• I went into tools->options->kits and modified the desktop kit to use my WinLua clang installation (found automagically by qtcreator).
• I have been able to save all the settings?
• Created a project and set it to build with CMake.
• The compiler was set to AArch64. Changed that in the project settings.
• Build and ran.

[longnguyen2004]

I downloaded Qt Creator from the github repo I think I might have chosen to create a qmake project, not a CMake project, so it doesn't let me save until it knows where qmake is. I'll try again later today.

About the current Python situation: We can either wait for my PR to be merged, or for distutils to be removed completely, which will make cross-compiling a whole lot easier, since a Python installation won't required to build CPython itself anymore.

[longnguyen2004]

Re: Size issues

For comparisons, WinLibs latest are 211MB in size (GCC + GDB + binutils, zipped) without Python. Considering that we haven't exceeded that, even with Python included, I'd say adding Python wouldn't hurt.

[I-Rinka]

Hello, I wonder where can I get lldb-mi for windows? (machine interface) I used to compile and use it on Linux but I think it would not directly work on Windows in this way. I'm using Windows on arm. How can I get lldb-mi for woa?

[longnguyen2004]

@I-Rinka Cherry-pick commit https://github.com/mstorsjo/llvm-mingw/commit/e9a2f7602b02ded3aa959cd0a0143e3a19795e39, resolve the merge conflicts if there's any, then build like usual.

[longnguyen2004]

Speaking of that, @mstorsjo I think we should build lldb-mi, even if it's in a separate repo, since a lot of IDE already support MI, and even those that don't explicitly support lldb will usually work anyway (albeit with some limitations).

[mstorsjo]

Speaking of that, @mstorsjo I think we should build lldb-mi, even if it's in a separate repo, since a lot of IDE already support MI, and even those that don't explicitly support lldb will usually work anyway (albeit with some limitations).

Sure, I can try to integrate building it, I'll put it on my todo.

[I-Rinka]

Speaking of that, @mstorsjo I think we should build lldb-mi, even if it's in a separate repo, since a lot of IDE already support MI, and even those that don't explicitly support lldb will usually work anyway (albeit with some limitations).

Yes, thank you. I have tried to compile the lldb-mi, the linux version and windows x64 version works fine. (I used docker to compile) But I found the aarch64 windows version failed to compile. I would wait for you to merge the lldb-mi project to current project.

[longnguyen2004]

What's the error? Maybe I can do something about it.

[I-Rinka]

What's the error? Maybe I can do something about it.

I entered the container and compile it manually to see what happened. It seems that the CMake scanned wrong directory to find the llvm-config.cmake

root@b863d070cc14:/build/llvm-project/llvm/cmake/modules# mv ./llvm-config.cmake ./llvmconfigcmake

I just used above method then it successefully find the llvm-config.cmake from the right path.

And finally through this way I successfully compiled it 😊

But ... ummm there is another problem when I try to use this on my aarch64 windows system. I try to solve it.

[longnguyen2004]

Hmm so it crashes when it hits a breakpoint. Does it work fine when there's no breakpoint?

0xC000001D is STATUS_ILLEGAL_INSTRUCTION, maybe an x86 instruction got through?

[I-Rinka]

Hmm so it crashes when it hits a breakpoint. Does it work fine when there's no breakpoint?

No, in fact it crashes at the start time.

[longnguyen2004]

We don't have an ARM machine laying around, so it's hard to reproduce the bug. Can you send over your lldb-mi build? I'll try to do some static analysis.

[I-Rinka]

We don't have an ARM machine laying around, so it's hard to reproduce the bug. Can you send over your lldb-mi build? I'll try to do some static analysis.

Of course. I uploaded it to my repository. lldb-mi-mingw-aarch64.exe:

https://github.com/I-Rinka/llvm-mingw/releases/download/20210423/lldb-mi-mingw-aarch64.exe

[I-Rinka]

We don't have an ARM machine laying around, so it's hard to reproduce the bug. Can you send over your lldb-mi build? I'll try to do some static analysis.

It seems not only the lldb-mi, but also the lldb encontering the same issue.

And if I enter 'n' to execute it step by step the program will abort. It shows it is aarch64 code when disassemble it, not x86.

[longnguyen2004]

Maybe your toolchain isn't built correctly. Try doing a proper 2-stage build (a cross compiler, then a native compiler) and try again (lldb-mi will be built in the process). Can you run your executable without the debugger?

[I-Rinka]

Maybe your toolchain isn't built correctly. Try doing a proper 2-stage build (a cross compiler, then a native compiler) and try again (lldb-mi will be built in the process). Can you run your executable without the debugger?

Of course. The executable runs.

I used to think it's my problem but it is weird because I try to compile the x64 version in the same way and the x64 version lldb-mi runs on another computer successfully. Then I download your release and run it, but it still has the same problem😰.

[longnguyen2004]

Is the executable itself ARM? Maybe Windows' x86 emulation is playing tricks on us here (if that's the case)

[I-Rinka]

Is the executable itself ARM? Maybe Windows' x86 emulation is playing tricks on us here (if that's the case)

It is arm. As I mentioned above. You can see the dissassembler is truly arm code.

[longnguyen2004]

Hmm, this is not easy to diagnose. I suggest you should create a new issue for this, to keep this issue clean and on point. We will continue the discussion there.

[acotty]

CodeLite 16.2.0

Codelite now has DAP support, so it can use the LLVM lldb-vscode DAP adapter.

Codelite DAP doc link: https://docs.codelite.org/plugins/dap/

[acotty]

Code::Blocks

The following github unofficial Code::Blocks source has DAP support (using the same DAP library as Codelite), so it can use the LLVM lldb-vscode DAP adapter.

The unofficial Code::Blocks source DAP doc link is: https://github.com/acotty/CodeBlocks_Unofficial_Testing/blob/master/src/plugins/contrib-wip/Debugger_DAP/Readme_DAP_setup.md