search

mstorsjo / llvm-mingw

An LLVM/Clang/LLD based mingw-w64 toolchain
Other
1.97k stars 188 forks source link

IDE Support for LLDB on Windows #186

Open RussellHaley opened 3 years ago

RussellHaley commented 3 years ago

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

Other questions:

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

longnguyen2004 commented 3 years ago

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 commented 3 years ago

Eclipse

1. Install the LLVM and LLDB support software

2. Setup the compiler

3. Setup the debugger

Happy debugging!

RussellHaley commented 3 years ago

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 commented 3 years ago

Visual Studio Code

1. Setup the compiler

2. Setup the debugger

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

longnguyen2004 commented 3 years ago

Code::Blocks

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

RussellHaley commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

RussellHaley commented 3 years ago

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.

longnguyen2004 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

I-Rinka commented 3 years ago

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

I entered the container and compile it manually to see what happened. wrong 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. image

And finally through this way I successfully compiled it 😊 image

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

image

longnguyen2004 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

image

image

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.

image

longnguyen2004 commented 3 years ago

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 commented 3 years ago

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

image

longnguyen2004 commented 3 years ago

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

I-Rinka commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Prohor327 commented 1 year ago

Hello, my question may seem stupid, but I'm new to this field, can you tell me what kind of program this is?