can't debug on macos using clion

[CaichaoGitHub]

details i built a simple project < example > successfully and i could run it directly , but i can't debug it clion just stuck on debug state and disable my breakpoints,

i tried to add some flags to command line , but it's not working -c dbg --spawn_strategy=standalone --strategy_regexp=^Linking=local

my environment: xcode : 12.0 clion: v2019.3.6 bazel plugin : v2020.07.13 bazel : release 3.5.0

[kekxv]

me too.

clion: 2020.3.4 bazel plugin : 2021.04.27.0.0 bazel : release 4.0.0

@AlexeyGy

[bedbad]

Still same problem

[Vertexwahn]

Same problem with CLion 2022.1.3 Bazel Plugin: 2022.07.25.0.1-api-version-221 Bazel: 5.2.0

[AlmogDavid]

Did someone was able to solve this issue?

[raoarun]

adding feedback from brandon adams (sorry i don't know their github handle):

debugging with clion works pretty well if you have a gdbinit which can detect running inside an execroot and add that to gdb's list of directories. Having this line: maybe_execroot = re.match(r'^(./bazel/bazel././execroot/roadrunner/).', filename)’.

[kkpattern]

I don't know if this will help, we are able to debug Android native in AndroidStudio build with bazel. The key is adding build --copt="-fdebug-compilation-dir" --copt="/proc/self/cwd". We need similar flags to debug iOS app in XCode that build with bazel.

It often caused by the sandbox path in symbols. above flag will replace the absolute paths in sandbox with cwd.

See #295

[raoarun]

update from isaac torres (seems similar to what @kkpattern has written above).

Hey all just wanted to give an update that I was able to implement a workaround for this issue. The problem seems to be that the debug binaries have the sandbox source paths (execroot) in them, and Clion (at least on macos), doesn't handle that. Mapping the execroot paths to the canonical paths fixes the problem. Probably with some fancy lldb/gdbinit scripting this can be generalized without having to hardcode absolute paths. I haven't tested yet but I'm assuming debugging works on linux so I'm curious that this works on one platform and not the other.

[emidln-imc]

Strictly speaking, my attached solution doesn't work very well for macos (given that you need a signed gdb which doesn't exist by default), but the general idea with lldb is the same as what I do for gdb. My solution works for gdb (if you happen to sign one) on MacOS and Linux:

https://gist.github.com/emidln-imc/54e69ed6b89cac9197d650222e6b18d9

[jungleraptor]

Theres a couple ideas that are floating around for kicking a general solution upstream now that it seems the root issue has been identified:

• Clion has a feature that allows users to remap source paths in order to debug binaries that were built on other machines. It implies there might be an API for doing this, and that API could be used to fix the mac debugging issue (simply map the workspace paths to the execroot paths before launching the debugger).
• Ship sufficiently generalized gdb/lldbinit scripts that set up the workspace/execroot mapping with the plugin.

Would be great to get some input from jetbrains or google if either of these ideas has any merit.

[sunqi1993]

update from isaac torres (seems similar to what @kkpattern has written above).

Hey all just wanted to give an update that I was able to implement a workaround for this issue. The problem seems to be that the debug binaries have the sandbox source paths (execroot) in them, and Clion (at least on macos), doesn't handle that. Mapping the execroot paths to the canonical paths fixes the problem. Probably with some fancy lldb/gdbinit scripting this can be generalized without having to hardcode absolute paths. I haven't tested yet but I'm assuming debugging works on linux so I'm curious that this works on one platform and not the other.

debugging works on linux platform, i have ever used this feature on manjaro but got stuck on macos :(

[tpasternak]

Just a short update:

1. It seems there's no GDB support for Mac M1, so we probably should target LLDB first
2. Unfortunately LLDB requires not only sources to be available but also either object files or dSYM files.
3. This means we have to either:

• remap only sources (via lldb settings target.source-map) and keep the object files in original paths (this means running --sandbox_debug or disabling sandbox at all)
• or remap both types of files.

4. The other solution is to make sure that the debugging info does not contain absolute paths. I'm trying to play with these flags: --debug-compilation-dir $PWD -Wl,--oso_prefix .

[kkpattern]

If considering remote cache and remote execution, making sure debugging info doesn't contain absolute paths is a preferable way.