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
- Allow oso_prefix_is_pwd to be used with all osx cpp link actions Expands the targeted actions to allow stripping the absolute build path for debug symbols from all libraries. The support in wrapped_... — committed to bazelbuild/bazel by jlaxson 3 years ago
- Add bazel.info.* commands (#291) I proposed these originally in https://github.com/bazelbuild/vscode-bazel/issues/273 as an initial idea for what became https://github.com/bazelbuild/vscode-bazel/pul... — committed to bazelbuild/vscode-bazel by jfirebaugh 2 years ago
+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):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 setsettings 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 ofbazel 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