5

I have started a C++ project in Visual Studio Code with Bazel build system. But debugging does not work in the IDE when the binary is built using Bazel.

I can debug application when built with clang++ -g main.cpp -o sample.

My setup: OS: MacOS, Bazel: release 0.17.2-homebrew, VS Code: 1.27.2

Which is caused by the way Bazel compiles. Is there any workaround to make debugging work?

Here is a minimal example. Just put a breakpoint in the editor, run debugging, and observe a breakpoint not being hit:

├── .vscode
│   ├── launch.json
│   └── tasks.json
├── BUILD
├── WORKSPACE
├── main.cpp
└── sample.code-workspace

.vscode/launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/bazel-bin/sample",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "externalConsole": false,
            "MIMode": "lldb",
            "preLaunchTask": "bazel build",
        }
    ]
}

.vscode/tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "bazel build",
            "type": "shell",
            "command": "bazel",
            "args": [
                "build",
                "--compilation_mode=dbg",
                "sample"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

BUILD

cc_binary(
    name = "sample",
    srcs = ["main.cpp"],
    visibility = ["//main:__pkg__"],
)

main.cpp

#include <iostream>

int main() {
    std::cout << "tests" << std::endl;
    return 0;
}

sample.code-workspace

{
    "folders": [ {"path": "."} ],
    "settings": {}
}

Upd. 1

Tried debugging bazel-built executable and manually-built directly with lldb:

Bazel-built binary bazel build --compilation_mode=dbg sample

lldb bazel-bin/sample
(lldb) breakpoint set -n main
Breakpoint 1: 13 locations.
(lldb) r
Process 24391 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001000021b0 sample`main
sample`main:
->  0x1000021b0 <+0>: pushq  %rbp
    0x1000021b1 <+1>: movq   %rsp, %rbp
    0x1000021b4 <+4>: subq   $0x20, %rsp
    0x1000021b8 <+8>: movq   0xe51(%rip), %rdi         ; (void *)0x00007fff9c93a660: std::__1::cout
Target 0: (sample) stopped.

Manually-built binary clang++ -g main.cpp -o sample

lldb sample
(lldb) breakpoint set -n main
Breakpoint 1: where = sample`main + 29 at main.cpp:4, address = 0x0000000100000f9d
(lldb) r
Process 24410 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100000f9d sample`main at main.cpp:4
   1    #include <iostream>
   2    
   3    int main() {
-> 4        std::cout << "tests" << std::endl;
   5        return 0;
   6    }
Target 0: (sample) stopped.

After looking up the "debug notes" in the executable (thanks to this answer)

nm -pa bazel-bin/sample | grep OSO
000000005bb7c96b - 03 0001   OSO /private/var/tmp/_bazel_teivaz/1e731ee5ae5a3ce6177976984318ec76/bazel-sandbox/1688134534644271312/execroot/__main__/bazel-out/darwin-dbg/bin/_objs/sample/main.o

I figured out that these paths point to the sandbox environment that Bazel used to build. And this path is no longer accessible.

This is likely caused by a known issue in Bazel #5545

Upd. 2

After updating Bazel to version 0.17.2 (where the issue #5545 is already fixed) this issue still occurs.

Upd. 3

In the end it turns out to be the Bazel problem. I have created an issue here #6327

Teivaz
  • 5,462
  • 4
  • 37
  • 75
  • Pretty sure you'll have better luck building and/or getting an answer if you throw out visual-studio-code. Run bazel from the command line, and show us that command, so we have an idea how it's actually being executed. Also tell us what you've done with respect to getting bazel to use compile options that are useful to debug. – Mark Oct 08 '18 at 22:23
  • @Mark I've added pure Bazel command to the updated part – Teivaz Oct 08 '18 at 22:28
  • so the actual problem is that you have no debug symbols? you say it "does not work" but it looks to me like you are able to attach just fine albeit with no symbols. – Brad Allred Oct 08 '18 at 22:42
  • @BradAllred I am able to attach debugger though the problem is that debugging in the IDE does not work – Teivaz Oct 08 '18 at 22:46
  • define "does not work" its completely unclear to me from you post. You have not provided an error at all. – Brad Allred Oct 08 '18 at 22:50
  • @BradAllred I consider dubugging in IDE as working if at least breakpoints are being hit. This is not the case here. I’ve made some research and added it as update to the post - debugger can be attached though the debug symbols are not mapped to the source properly thus the problem. – Teivaz Oct 08 '18 at 22:54
  • so exactly what I said before: Your problem isnt that it does not work, but rather that you are stripping the symbols out of your binary so your symbolic breakpoints dont work because there are no symbols to resolve them. It may be that VSC strips them in favor of providing a `dwarf` file. if so simply give that file to lldb as an option. – Brad Allred Oct 08 '18 at 23:12
  • A quick note: 1. `workspaceRoot` has been deprecated in favor of `workspaceFolder` 2. I tested this with bazel version 4.0.0 and it seems that `--sandbox_debug=true` flag is no longer required in order to be able to debug – sdevikar May 13 '21 at 15:45

3 Answers3

3

For anyone else stumbling upon this issue, the following worked for me (March 2022):

.bazelrc:

build:debug -c dbg
build:debug --features=oso_prefix_is_pwd

Then build using:

bazel build --config debug //project/path:name

The .bazelrc can be either in your home directory, or in the same directory as bazel's WORKSPACE file

jtlim
  • 3,861
  • 1
  • 16
  • 14
  • It made a big difference! Before I was not able to get dbgger to stop at any breakpoints, not it can. The sad thing is vscode still cannot load source file, saying error: `'SourceRequest' not supported` – danielyan86129 Nov 21 '22 at 03:55
2

(Promoting updates to answer): Looks like a known issue: #6327

Christopher Parsons
  • 337
  • 1
  • 3
0

Let GDB find the correct file.

.vscode/launch.json

{
    // ...
    "configurations": [
        {
            // ...
            "preLaunchCommands": [
                "directory ${workspaceFolder}" // or absolute path to your workspace
            ],
        }
    ]
}
Jalon
  • 1
  • 3