FR: Debugger setup in vscode

[UebelAndre]

Is there a suggested method to setup a debugger against a rust target in Visual Studio Code?

[damienmg]

Hi Uebel, I don't think there is any. I tend to use lldb directly after a build in -c dbg mode.

[UebelAndre]

Ah, ok. Sorry for the delay and thank you @damienmg in particular for answering being so active 😄

[damienmg]

No worries, I want to keep this bug open as I think it represent a reasonable feature request (though probably a low priority one).

[UebelAndre]

@damienmg Can you give an example of a command you run?

[damienmg]

That's all in the command line like:

$ bazel build -c dbg //my:target
$ lddb bazel-bin/my/target

[UebelAndre]

That's all in the command line like:

$ bazel build -c dbg //my:target

$ lddb bazel-bin/my/target

Oh, is there no way to pass lldb as an argument to bazel run? That was my original hope 😅

[damienmg]

There should be the --run_under flag of `bazel run` but quite frankly I have never used it for debugging rust binary so I would not be able to help here. Also this is more important for debugging test where a huge setup is done outside the binary.

[klochek]

Hi! I just ran into this today, and had to work around a few things to get lldb debugging under vscode (on linux) to work. I thought I might share this in case someone needs to get this working ASAP (or wants to turn this into a patch...?)

In debug builds, rustc writes the source files' absolute paths to the target binary, which means those paths will be in whatever sandbox directory Bazel was using for building. Thus, when you try to debug that binary, and lldb tries to map some code to a file, it goes looking for a source file in a sandbox directory that no longer exists, and so you can't see the source, set breakpoints, inspect variables, etc.

Happily, rustc exposes a compiler option, --remap-path-prefix=FROM=TO, to deal with this kind of situation. I patched my local version of rules_rust to include the following arg during invocation: args.add("--remap-path-prefix=${pwd}/=workspace/") I'm mapping the action sandbox directory to "workspace/", and so all source file paths written to the binaries have "workspace/" as the root. Then, you just provide a mapping from "workspace/" to your WORKSPACE root in vscode, and then everything works as expected.

I tried to get rid of the "workspace" root entirely, but it didn't work; I think perhaps vscode is expecting absolute paths to source files when doing sourcemaps, and so you need to map something to your workspace directory.

[hlopko]

Hi all, small update. Rust rules now pass (simplifying here a bit) --remap-path-prefix=$PWD=.. There are some options to debug things:

1. in the root of bazel workspace run bazel build //foo:bar -c dbg; lldb bazel-bin/foo/bar and you should see the sources.
2. when using --run_under we need to change the directory because bazel by default sets cwd to the runfiles. This should work: bazel run //foo:bar -c dbg --run_under="cd \"\${BUILD_WORKSPACE_DIRECTORY}\" && lldb".
3. when using VSCode, and using CodeLLDB, this config works:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug //foo:bar",
            "program": "${workspaceFolder}/bazel-bin/foo/bar",
            "args": [],
            "sourceMap": {
                ".": "${workspaceFolder}/"
            },
        },
    ]
}

You can put the sourceMap into your settings.json, then you don't have to specify it in the launch.json all the time:

"lldb.launch.sourceMap": {
    ".": "${workspaceFolder}",
},

Last but not least, there was a regression in rust-lang/rust@2ba7ca2 that was fixed in rust-lang/rust#82102. The fix is only in nightlies currently and will be released in 1.52.

Anybody would be willing to get this rough text and make a nice documentation out of it?

[UebelAndre]

Oh, I totally missed #370 (comment) and just came to link #812 (comment) 😅

It'd be awesome if someone could add this to the rust_analyzer docs.