CodeLLDB¶
Languages: Rust, C, C++ · Transport: TCP
The catalog entry:
[adapters.codelldb]
id = "codelldb"
command = "codelldb"
tcp_argument = "--port={port}"
transport = { tcp = { host = "127.0.0.1" } }
Bugsaur picks a free port, passes it as --port=<port> and connects to
127.0.0.1.
Install¶
Install CodeLLDB and put the binary on
PATH:
If it came from Mason:
Verify¶
If that runs, the adapter is installed. If a session still fails to start, the
debugger cannot see it — check PATH in the environment Bugsaur runs in, which
is not necessarily the one your shell has.
No build step¶
The catalog gives CodeLLDB no build entry, so Bugsaur builds nothing for it:
it receives a binary that already exists. For Rust that means cargo build
first; for C and C++, your own build command.
program in the profile is a compiled binary, not a source file or
directory.
Build with debug information¶
An optimised binary has little for a debugger to work with — variables read as optimised out, frames get inlined away, breakpoints land on unexpected lines.
- Rust: use the debug build, not
--release. - C / C++:
-g -O0.
Attaching¶
[profiles.attach]
adapter = "codelldb"
program = "build/app"
mode = "attach"
[profiles.attach.launch_arguments]
pid = 4242
Adapter-specific settings¶
Anything CodeLLDB accepts that has no field in the profile schema goes through
launch_arguments, unchanged:
Bugsaur does not interpret these — the meaning is CodeLLDB's. See its own documentation for the full list.
Diagnostics¶
| Symptom | Cause | Fix |
|---|---|---|
| Session never starts | codelldb not on PATH |
check command -v; or set adapter_command |
program is not readable |
the binary is not built | build it first |
| Variables show as optimised out | release / optimised build | rebuild in debug, -g -O0 |
| Breakpoints do not bind | non-executable lines, or no debug info | Breakpoints not hit |
| No source for your own frames | paths moved since the build | Source not found |