3 ## Procuring the `lldb-dap` binary
5 The extension requires the `lldb-dap` (formerly `lldb-vscode`) binary.
6 This binary is not packaged with the VS Code extension.
8 There are multiple ways to obtain this binary:
9 * Use the binary provided by your toolchain (for example `xcrun -f lldb-dap` on macOS) or contact your toolchain vendor to include it.
10 * Download one of the relase packages from the [LLVM release page](https://github.com/llvm/llvm-project/releases/). The `LLVM-19.1.0-{operating_system}.tar.xz` packages contain a prebuilt `lldb-dap` binary.
11 * Build it from source (see [LLDB's build instructions](https://lldb.llvm.org/resources/build.html)).
13 By default, the VS Code extension will expect to find `lldb-dap` in your `PATH`.
14 Alternatively, you can explictly specify the location of the `lldb-dap` binary using the `lldb-dap.executable-path` setting.
16 ### Usage with other IDEs
18 The `lldb-dap` binary is a command line tool that implements the [Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol/).
19 It is used to power the VS Code extension but can also be used with other IDEs and editors that support DAP.
20 The protocol is easy to run remotely and also can allow other tools and IDEs to get a full featured debugger with a well defined protocol.
22 ## Launching & Attaching to a debugee
24 Launching or attaching a debugee require you to create a [launch configuration](https://code.visualstudio.com/Docs/editor/debugging#_launch-configurations).
25 This file defines arguments that get passed to `lldb-dap` and the configuration settings control how the launch or attach happens.
27 ### Launching a debugee
29 This will launch `/tmp/a.out` with arguments `one`, `two`, and `three` and
30 adds `FOO=1` and `bar` to the environment:
37 "program": "/tmp/a.out",
38 "args": [ "one", "two", "three" ],
46 ### Attaching to a process
48 When attaching to a process using LLDB, you can attach in multiple ways:
50 1. Attach to an existing process using the process ID
51 2. Attach to an existing process by name
52 3. Attach by name by waiting for the next instance of a process to launch
56 This will attach to a process `a.out` whose process ID is 123:
62 "name": "Attach to PID",
63 "program": "/tmp/a.out",
70 This will attach to an existing process whose base
71 name matches `a.out`. All we have to do is leave the `pid` value out of the
76 "name": "Attach to Name",
79 "program": "/tmp/a.out",
83 If you want to ignore any existing a.out processes and wait for the next instance
84 to be launched you can add the "waitFor" key value pair:
88 "name": "Attach to Name (wait)",
91 "program": "/tmp/a.out",
96 This will work as long as the architecture, vendor and OS supports waiting
97 for processes. Currently MacOS is the only platform that supports this.
99 ### Loading a Core File
101 This loads the coredump file `/cores/123.core` associated with the program
106 "name": "Load coredump",
109 "coreFile": "/cores/123.core",
110 "program": "/tmp/a.out"
114 ### Connect to a Debug Server on the Current Machine
116 This connects to a debug server (e.g. `lldb-server`, `gdbserver`) on
117 the current machine, that is debugging the program `/tmp/a.out` and listening
118 locally on port `2345`.
122 "name": "Local Debug Server",
125 "program": "/tmp/a.out",
126 "attachCommands": ["gdb-remote 2345"],
130 You can also use the `gdb-remote-port` parameter to send an attach request
131 to a debug server running on the current machine,
132 instead of using the custom command `attachCommands`.
136 "name": "Local Debug Server",
139 "program": "/tmp/a.out",
140 "gdb-remote-port": 2345,
144 ### Connect to a Debug Server on Another Machine
146 This connects to a debug server running on another machine with hostname
147 `hostnmame`. Which is debugging the program `/tmp/a.out` and listening on
148 port `5678` of that other machine.
152 "name": "Remote Debug Server",
155 "program": "/tmp/a.out",
156 "attachCommands": ["gdb-remote hostname:5678"],
160 You can also use the `gdb-remote-hostname` and `gdb-remote-port` parameters
161 to send an attach request to a debug server running on a different machine,
162 instead of custom command `attachCommands`.
163 The default hostname being used `localhost`.
168 "name": "Local Debug Server",
171 "program": "/tmp/a.out",
172 "gdb-remote-port": 5678,
173 "gdb-remote-hostname": "hostname",
177 ### Configuration Settings Reference
179 For both launch and attach configurations, lldb-dap accepts the following `lldb-dap`
180 specific key/value pairs:
182 | Parameter | Type | Req | |
183 |-----------------------------------|-------------|:---:|---------|
184 | **name** | string | Y | A configuration name that will be displayed in the IDE.
185 | **type** | string | Y | Must be "lldb-dap".
186 | **request** | string | Y | Must be "launch" or "attach".
187 | **program** | string | Y | Path to the executable to launch.
188 | **sourcePath** | string | | Specify a source path to remap \"./\" to allow full paths to be used when setting breakpoints in binaries that have relative source paths.
189 | **sourceMap** | [string[2]] | | Specify an array of path re-mappings. Each element in the array must be a two element array containing a source and destination pathname. Overrides sourcePath.
190 | **debuggerRoot** | string | | Specify a working directory to use when launching lldb-dap. If the debug information in your executable contains relative paths, this option can be used so that `lldb-dap` can find source files and object files that have relative paths.
191 | **commandEscapePrefix** | string | | The escape prefix to use for executing regular LLDB commands in the Debug Console, instead of printing variables. Defaults to a backtick. If it's an empty string, then all expression in the Debug Console are treated as regular LLDB commands.
192 | **customFrameFormat** | string | | If non-empty, stack frames will have descriptions generated based on the provided format. See https://lldb.llvm.org/use/formatting.html for an explanation on format strings for frames. If the format string contains errors, an error message will be displayed on the Debug Console and the default frame names will be used. This might come with a performance cost because debug information might need to be processed to generate the description.
193 | **customThreadFormat** | string | | Same as `customFrameFormat`, but for threads instead of stack frames.
194 | **displayExtendedBacktrace** | bool | | Enable language specific extended backtraces.
195 | **enableAutoVariableSummaries** | bool | | Enable auto generated summaries for variables when no summaries exist for a given type. This feature can cause performance delays in large projects when viewing variables.
196 | **enableSyntheticChildDebugging** | bool | | If a variable is displayed using a synthetic children, also display the actual contents of the variable at the end under a [raw] entry. This is useful when creating sythetic child plug-ins as it lets you see the actual contents of the variable.
197 | **initCommands** | [string] | | LLDB commands executed upon debugger startup prior to creating the LLDB target.
198 | **preRunCommands** | [string] | | LLDB commands executed just before launching/attaching, after the LLDB target has been created.
199 | **stopCommands** | [string] | | LLDB commands executed just after each stop.
200 | **exitCommands** | [string] | | LLDB commands executed when the program exits.
201 | **terminateCommands** | [string] | | LLDB commands executed when the debugging session ends.
203 All commands and command outputs will be sent to the debugger console when they are executed.
204 Commands can be prefixed with `?` or `!` to modify their behavior:
205 * Commands prefixed with `?` are quiet on success, i.e. nothing is written to stdout if the command succeeds.
206 * Prefixing a command with `!` enables error checking: If a command prefixed with `!` fails, subsequent commands will not be run. This is usefule if one of the commands depends on another, as it will stop the chain of commands.
208 For JSON configurations of `"type": "launch"`, the JSON configuration can additionally
209 contain the following key/value pairs:
211 | Parameter | Type | Req | |
212 |-----------------------------------|-------------|:---:|---------|
213 | **program** | string | Y | Path to the executable to launch.
214 | **args** | [string] | | An array of command line argument strings to be passed to the program being launched.
215 | **cwd** | string | | The program working directory.
216 | **env** | dictionary | | Environment variables to set when launching the program. The format of each environment variable string is "VAR=VALUE" for environment variables with values or just "VAR" for environment variables with no values.
217 | **stopOnEntry** | boolean | | Whether to stop program immediately after launching.
218 | **runInTerminal** | boolean | | Launch the program inside an integrated terminal in the IDE. Useful for debugging interactive command line programs.
219 | **launchCommands** | [string] | | LLDB commands executed to launch the program.
221 For JSON configurations of `"type": "attach"`, the JSON configuration can contain
222 the following `lldb-dap` specific key/value pairs:
224 | Parameter | Type | Req | |
225 |-----------------------------------|-------------|:---:|---------|
226 | **program** | string | | Path to the executable to attach to. This value is optional but can help to resolve breakpoints prior the attaching to the program.
227 | **pid** | number | | The process id of the process you wish to attach to. If **pid** is omitted, the debugger will attempt to attach to the program by finding a process whose file name matches the file name from **porgram**. Setting this value to `${command:pickMyProcess}` will allow interactive process selection in the IDE.
228 | **waitFor** | boolean | | Wait for the process to launch.
229 | **attachCommands** | [string] | | LLDB commands that will be executed after **preRunCommands** which take place of the code that normally does the attach. The commands can create a new target and attach or launch it however desired. This allows custom launch and attach configurations. Core files can use `target create --core /path/to/core` to attach to core files.
233 The Debug Console allows printing variables / expressions and executing lldb commands.
234 By default, lldb-dap tries to auto-detect whether a provided command is a variable
235 name / expression whose values will be printed to the Debug Console or a LLDB command.
236 To side-step this auto-detection and execute a LLDB command, prefix it with the
237 `commandEscapePrefix`.
239 The auto-detection can be disabled using the `lldb-dap repl-mode` command.
240 The escape character can be adjusted via the `commandEscapePrefix` configuration option.
242 ### lldb-dap specific commands
244 The `lldb-dap` tool includes additional custom commands to support the Debug
245 Adapter Protocol features.
247 #### `lldb-dap start-debugging`
249 Using the command `lldb-dap start-debugging` it is possible to trigger a
250 reverse request to the client requesting a child debug session with the
251 specified configuration. For example, this can be used to attached to forked or
252 spawned processes. For more information see
253 [Reverse Requests StartDebugging](https://microsoft.github.io/debug-adapter-protocol/specification#Reverse_Requests_StartDebugging).
255 The custom command has the following format:
258 lldb-dap start-debugging <launch|attach> <configuration>
261 This will launch a server and then request a child debug session for a client.
267 "lldb-dap start-debugging launch '{\"program\":\"client\"}'"
272 #### `lldb-dap repl-mode`
274 Inspect or adjust the behavior of lldb-dap repl evaluation requests. The
275 supported modes are `variable`, `command` and `auto`.
277 - `variable` - Variable mode expressions are evaluated in the context of the
279 - `command` - Command mode expressions are evaluated as lldb commands, as a
280 result, values printed by lldb are always stringified representations of the
282 - `auto` - Auto mode will attempt to infer if the expression represents an lldb
283 command or a variable expression. A heuristic is used to infer if the input
284 represents a variable or a command.
286 In all three modes, you can use the `commandEscapePrefix` to ensure an expression
287 is evaluated as a command.
289 The initial repl-mode can be configured with the cli flag `--repl-mode=<mode>`
290 and may also be adjusted at runtime using the lldb command
291 `lldb-dap repl-mode <mode>`.
293 #### `lldb-dap send-event`
295 lldb-dap includes a command to trigger a Debug Adapter Protocol event
298 The event maybe a custom DAP event or a standard event, if the event is not
299 handled internally by `lldb-dap`.
301 This command has the format:
304 lldb-dap send-event <name> <body>?
307 For example you can use a launch configuration hook to trigger custom events like:
313 "lldb-dap send-event MyStopEvent",
314 "lldb-dap send-event MyStopEvent '{\"key\": 321}",
319 [See the specification](https://microsoft.github.io/debug-adapter-protocol/specification#Base_Protocol_Event)
320 for more details on Debug Adapter Protocol events and the VS Code
321 [debug.onDidReceiveDebugSessionCustomEvent](https://code.visualstudio.com/api/references/vscode-api#debug.onDidReceiveDebugSessionCustomEvent)
322 API for handling a custom event from an extension.
326 `lldb-dap` and `lldb` are developed under the umbrella of the [LLVM project](https://llvm.org/).
327 The source code is [part of the LLVM repository](https://github.com/llvm/llvm-project/tree/main/lldb/tools/lldb-dap) on Github.
328 We use Github's [issue tracker](https://github.com/llvm/llvm-project/tree/main/lldb/tools/lldb-dap) and patches can be submitted via [pull requests](https://github.com/llvm/llvm-project/pulls).
329 Furthermore, there is a [LLDB category](https://discourse.llvm.org/c/subprojects/lldb/8) on the LLVM discourse forum.
331 For instructions on how to get started with development on lldb-dap, see the "[Contributing to lldb-dap](https://lldb.llvm.org/resources/lldbdap.html)"