rules_rust icon indicating copy to clipboard operation
rules_rust copied to clipboard

FR: Debugger setup in vscode

Open UebelAndre opened this issue 5 years ago • 10 comments

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

UebelAndre avatar Jul 17 '20 02:07 UebelAndre

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

damienmg avatar Jul 17 '20 09:07 damienmg

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

UebelAndre avatar Jul 21 '20 13:07 UebelAndre

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

damienmg avatar Jul 21 '20 13:07 damienmg

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

UebelAndre avatar Nov 25 '20 05:11 UebelAndre

That's all in the command line like:

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

damienmg avatar Nov 25 '20 14:11 damienmg

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 😅

UebelAndre avatar Nov 25 '20 14:11 UebelAndre

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.

damienmg avatar Nov 25 '20 15:11 damienmg

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.

klochek avatar Dec 05 '20 02:12 klochek

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 https://github.com/rust-lang/rust/commit/2ba7ca2bbbff6cd424aebc654308febc00b9497a that was fixed in https://github.com/rust-lang/rust/pull/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?

hlopko avatar Mar 11 '21 09:03 hlopko

Oh, I totally missed https://github.com/bazelbuild/rules_rust/issues/370#issuecomment-796592288 and just came to link https://github.com/bazelbuild/rules_rust/issues/812#issuecomment-884898750 😅

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

UebelAndre avatar Jul 22 '21 15:07 UebelAndre