bazel: Debugging C++ on MacOS does not work

Description of the problem / feature request:

Debugging C++ on MacOS does not work. The built binary file contains debug hints which point to the location in the sandbox (which is removed after compilation).

Feature requests: what underlying problem are you trying to solve with this feature?

Replace this line with your answer.

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

BUILD file

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

main.cpp file

#include <iostream>

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

Build with bazel build --compilation_mode=dbg sample And debug

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.

Debug hints in the executable:

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

While file built with clang++ -g main.cpp -o sample can be debugged normally:

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.

What operating system are you running Bazel on?

MacOS High Sierra 10.13.2

What’s the output of bazel info release?

release 0.17.2-homebrew

Have you found anything relevant by searching the web?

I have found related issue 5545 but the proposed solution was already merged to the version of Bazel I am using.

Any other information, logs, or outputs that you want to share?

I have also asked a question on Stackoverflow

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 25
  • Comments: 22 (12 by maintainers)

Commits related to this issue

Most upvoted comments

+1 - would love to see this fixed

As of today I think most of the issues are resolved, but unfortunately not enabled by default (and realistically probably can’t be since some might require extra lldb configuration).

Note that I’m testing with bazel HEAD (although I think the current 5.x release has the same fixes)

For the original repro case here, using --features=oso_prefix_is_pwd is enough to get this to work. This results in the binary containing relative paths to the object files, so they are no longer affected by the temporary sandboxing paths.

A while back I also made debug_prefix_map_pwd_is_dot default to true, which likely covered another case here. Note that in some cases you likely need to set some LLDB configuration because of this, something like (note you have to replace $PWD with your project’s actual PWD):

platform settings -w $PWD
settings set target.source-map ./ $PWD

You can set this in your ~/.lldbinit, or you can create a project local .lldbinit, but if you do the latter you either have to launch lldb with --local-lldbinit or you have to set settings set target.load-cwd-lldbinit true in your ~/.lldbinit for security.

If folks have more cases that don’t work please post them here.

I found that platform settings -w need to be provided the Bazel execution root (i.e. the output of bazel info execution_root), not the workspace root or working directory.

@kastiglione Yes it is another workaround though I would like not to use it. I have found another workaround - disabling sandbox with --spawn_strategy=standalone. But none of them solves the issue.

I think we can add https://github.com/bazelbuild/bazel/issues/1000 to the list of related issues