default launch debug attempts to use unsupported debuggers

[L0laapk3]

Brief Issue Summary

Cmaketools attempts to launch lldb on linux, something that is explicitely not supported by cpptools.

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

I am using the following kit on a fresh WSL debian machine:

  {
    "name": "Clang 18.1.3 x86_64-pc-linux-gnu",
    "compilers": {
      "C": "/usr/bin/clang-18",
      "CXX": "/usr/bin/clang++-18"
    },
    "isTrusted": true
  },

When launching the default cmaketools debugger target, without manually supplying a launch.json, the following debuggers are tried in the following order:

/usr/bin/lldb-mi-18
/home/<USER>/.vscode-server/extensions/ms-vscode.cpptools-1.19.9-linux-x64/debugAdapters/lldb-mi/bin/lldb-mi
/usr/bin/gdb-18
/usr/bin/lldb-18 # it finds this one, leading to errors..
/usr/bin/gdb
...

It should not try to launch lldb debuggers on the linux platform since those are not supported.

Sidenote: Is there a setting to manually override this scanning behavior and instead supply a debugger path yourself, without having to define an entire launch.json file? That would be nice.

[bobbrow]

Sidenote: Is there a setting to manually override this scanning behavior and instead supply a debugger path yourself, without having to define an entire launch.json file? That would be nice.

Yes, add something like this to your settings.json file:

"cmake.debugConfig": {
  "MIMode": "gdb" // or "lldb"
  "miDebuggerPath": "/path/to/debugger"
}

[gcampbell-msft]

Thanks @bobbrow. I'll close this issue since there is a way to set which debugger to use. Thanks!

[L0laapk3]

Thanks @bobbrow, your suggestion worked flawlessly. I could not find this in documentation.

@gcampbell-msft, in my opinion, "default launch debug attempts to use unsupported debuggers" is still an issue regardless of the available workaround.

[L0laapk3]

The issue is not solved and I dont agree with it being marked as such.

[v-frankwang]

@L0laapk3 Thank you very much for your response, we've reopened this issue and added it to the backlog