debugger.md

  1# Debugger (Beta)
  2
  3Zed uses the Debug Adapter Protocol (DAP) to provide debugging functionality across multiple programming languages.
  4DAP is a standardized protocol that defines how debuggers, editors, and IDEs communicate with each other.
  5It allows Zed to support various debuggers without needing to implement language-specific debugging logic.
  6This protocol enables features like setting breakpoints, stepping through code, inspecting variables,
  7and more, in a consistent manner across different programming languages and runtime environments.
  8
  9## Supported Debug Adapters
 10
 11Zed supports a variety of debug adapters for different programming languages:
 12
 13- JavaScript (node): Enables debugging of Node.js applications, including setting breakpoints, stepping through code, and inspecting variables in JavaScript.
 14
 15- Python (debugpy): Provides debugging capabilities for Python applications, supporting features like remote debugging, multi-threaded debugging, and Django/Flask application debugging.
 16
 17- LLDB: A powerful debugger for C, C++, Objective-C, and Swift, offering low-level debugging features and support for Apple platforms.
 18
 19- GDB: The GNU Debugger, which supports debugging for multiple programming languages including C, C++, Go, and Rust, across various platforms.
 20
 21- Go (dlv): Delve, a debugger for the Go programming language, offering both local and remote debugging capabilities with full support for Go's runtime and standard library.
 22
 23- PHP (xdebug): Provides debugging and profiling capabilities for PHP applications, including remote debugging and code coverage analysis.
 24
 25These adapters enable Zed to provide a consistent debugging experience across multiple languages while leveraging the specific features and capabilities of each debugger.
 26
 27Additionally, Ruby support (via rdbg) is being actively worked on.
 28
 29## Getting Started
 30
 31For basic debugging, you can set up a new configuration by opening the `New Session Modal` either via the `debugger: start` (default: f4) or by clicking the plus icon at the top right of the debug panel.
 32
 33For more advanced use cases, you can create debug configurations by directly editing the `.zed/debug.json` file in your project root directory.
 34
 35You can then use the `New Session Modal` to select a configuration and start debugging.
 36
 37### Launching & Attaching
 38
 39Zed debugger offers two ways to debug your program; you can either _launch_ a new instance of your program or _attach_ to an existing process.
 40Which one you choose depends on what you are trying to achieve.
 41
 42When launching a new instance, Zed (and the underlying debug adapter) can often do a better job at picking up the debug information compared to attaching to an existing process, since it controls the lifetime of a whole program. Running unit tests or a debug build of your application is a good use case for launching.
 43
 44Compared to launching, attaching to an existing process might seem inferior, but that's far from truth; there are cases where you cannot afford to restart your program, because e.g. the bug is not reproducible outside of a production environment or some other circumstances.
 45
 46## Configuration
 47
 48While configuration fields are debug adapter-dependent, most adapters support the following fields:
 49
 50```json
 51[
 52  {
 53    // The label for the debug configuration and used to identify the debug session inside the debug panel & new session modal
 54    "label": "Example Start debugger config",
 55    // The debug adapter that Zed should use to debug the program
 56    "adapter": "Example adapter name",
 57    // Request:
 58    //  - launch: Zed will launch the program if specified or shows a debug terminal with the right configuration
 59    //  - attach: Zed will attach to a running program to debug it or when the process_id is not specified we will show a process picker (only supported for node currently)
 60    "request": "launch",
 61    // program: The program that you want to debug
 62    // This field supports path resolution with ~ or . symbols
 63    "program": "path_to_program",
 64    // cwd: defaults to the current working directory of your project ($ZED_WORKTREE_ROOT)
 65    "cwd": "$ZED_WORKTREE_ROOT"
 66  }
 67]
 68```
 69
 70All configuration fields support task variables. See [Tasks Variables](./tasks.md#variables)
 71
 72### Build tasks
 73
 74Zed also allows embedding a Zed task in a `build` field that is run before the debugger starts. This is useful for setting up the environment or running any necessary setup steps before the debugger starts.
 75
 76```json
 77[
 78  {
 79    "label": "Build Binary",
 80    "adapter": "CodeLLDB",
 81    "program": "path_to_program",
 82    "request": "launch",
 83    "build": {
 84      "command": "make",
 85      "args": ["build", "-j8"]
 86    }
 87  }
 88]
 89```
 90
 91Build tasks can also refer to the existing tasks by unsubstituted label:
 92
 93```json
 94[
 95  {
 96    "label": "Build Binary",
 97    "adapter": "CodeLLDB",
 98    "program": "path_to_program",
 99    "request": "launch",
100    "build": "my build task" // Or "my build task for $ZED_FILE"
101  }
102]
103```
104
105### Automatic scenario creation
106
107Given a Zed task, Zed can automatically create a scenario for you. Automatic scenario creation also powers our scenario creation from gutter.
108Automatic scenario creation is currently supported for Rust, Go and Python. Javascript/TypeScript support being worked on.
109
110### Example Configurations
111
112#### JavaScript
113
114##### Debug Active File
115
116```json
117[
118  {
119    "label": "Debug with node",
120    "adapter": "JavaScript",
121    "program": "$ZED_FILE",
122    "request": "launch",
123    "console": "integratedTerminal",
124    "type": "pwa-node"
125  }
126]
127```
128
129##### Attach debugger to a server running in web browser (`npx serve`)
130
131Given an externally-ran web server (e.g. with `npx serve` or `npx live-server`) one can attach to it and open it with a browser.
132
133```json
134[
135  {
136    "label": "Inspect ",
137    "adapter": "JavaScript",
138    "type": "pwa-chrome",
139    "request": "launch",
140    "url": "http://localhost:5500", // Fill your URL here.
141    "program": "$ZED_FILE",
142    "webRoot": "${ZED_WORKTREE_ROOT}"
143  }
144]
145```
146
147#### Python
148
149##### Debug Active File
150
151```json
152[
153  {
154    "label": "Python Active File",
155    "adapter": "Debugpy",
156    "program": "$ZED_FILE",
157    "request": "launch"
158  }
159]
160```
161
162##### Flask App
163
164For a common Flask Application with a file structure similar to the following:
165
166```
167.venv/
168app/
169  init.py
170  main.py
171  routes.py
172templates/
173  index.html
174static/
175  style.css
176requirements.txt
177```
178
179the following configuration can be used:
180
181```json
182[
183  {
184    "label": "Python: Flask",
185    "adapter": "Debugpy",
186    "request": "launch",
187    "module": "app",
188    "cwd": "$ZED_WORKTREE_ROOT",
189    "env": {
190      "FLASK_APP": "app",
191      "FLASK_DEBUG": "1"
192    },
193    "args": [
194      "run",
195      "--reload", // Enables Flask reloader that watches for file changes
196      "--debugger" // Enables Flask debugger
197    ],
198    "autoReload": {
199      "enable": true
200    },
201    "jinja": true,
202    "justMyCode": true
203  }
204]
205```
206
207#### Rust/C++/C
208
209##### Using pre-built binary
210
211```json
212[
213  {
214    "label": "Debug native binary",
215    "program": "$ZED_WORKTREE_ROOT/build/binary",
216    "request": "launch",
217    "adapter": "CodeLLDB" // GDB is available on non arm macs as well as linux
218  }
219]
220```
221
222##### Build binary then debug
223
224```json
225[
226  {
227    "label": "Build & Debug native binary",
228    "build": {
229      "command": "cargo",
230      "args": ["build"]
231    },
232    "program": "$ZED_WORKTREE_ROOT/target/debug/binary",
233    "request": "launch",
234    "adapter": "CodeLLDB" // GDB is available on non arm macs as well as linux
235  }
236]
237```
238
239#### TypeScript
240
241##### Attach debugger to a server running in web browser (`npx serve`)
242
243Given an externally-ran web server (e.g. with `npx serve` or `npx live-server`) one can attach to it and open it with a browser.
244
245```json
246[
247  {
248    "label": "Launch Chromee (TypeScript)",
249    "adapter": "JavaScript",
250    "type": "pwa-chrome",
251    "request": "launch",
252    "url": "http://localhost:5500",
253    "program": "$ZED_FILE",
254    "webRoot": "${ZED_WORKTREE_ROOT}",
255    "sourceMaps": true,
256    "build": {
257      "command": "npx",
258      "args": ["tsc"]
259    }
260  }
261]
262```
263
264## Breakpoints
265
266To set a breakpoint, simply click next to the line number in the editor gutter.
267Breakpoints can be tweaked dependending on your needs; to access additional options of a given breakpoint, right-click on the breakpoint icon in the gutter and select the desired option.
268At present, you can:
269
270- Add a log to a breakpoint, which will output a log message whenever that breakpoint is hit.
271- Make the breakpoint conditional, which will only stop at the breakpoint when the condition is met. The syntax for conditions is adapter-specific.
272- Add a hit count to a breakpoint, which will only stop at the breakpoint after it's hit a certain number of times.
273- Disable a breakpoint, which will prevent it from being hit while leaving it visible in the gutter.
274
275Some debug adapters (e.g. CodeLLDB and JavaScript) will also _verify_ whether your breakpoints can be hit; breakpoints that cannot be hit are surfaced more prominently in the UI.
276
277All breakpoints enabled for a given project are also listed in "Breakpoints" item in your debugging session UI. From "Breakpoints" item in your UI you can also manage exception breakpoints.
278The debug adapter will then stop whenever an exception of a given kind occurs. Which exception types are supported depends on the debug adapter.
279
280## Settings
281
282- `stepping_granularity`: Determines the stepping granularity.
283- `save_breakpoints`: Whether the breakpoints should be reused across Zed sessions.
284- `button`: Whether to show the debug button in the status bar.
285- `timeout`: Time in milliseconds until timeout error when connecting to a TCP debug adapter.
286- `log_dap_communications`: Whether to log messages between active debug adapters and Zed.
287- `format_dap_log_messages`: Whether to format DAP messages when adding them to the debug adapter logger.
288
289### Stepping granularity
290
291- Description: The Step granularity that the debugger will use
292- Default: line
293- Setting: debugger.stepping_granularity
294
295**Options**
296
2971. Statement - The step should allow the program to run until the current statement has finished executing.
298   The meaning of a statement is determined by the adapter and it may be considered equivalent to a line.
299   For example 'for(int i = 0; i < 10; i++)' could be considered to have 3 statements 'int i = 0', 'i < 10', and 'i++'.
300
301```json
302{
303  "debugger": {
304    "stepping_granularity": "statement"
305  }
306}
307```
308
3092. Line - The step should allow the program to run until the current source line has executed.
310
311```json
312{
313  "debugger": {
314    "stepping_granularity": "line"
315  }
316}
317```
318
3193. Instruction - The step should allow one instruction to execute (e.g. one x86 instruction).
320
321```json
322{
323  "debugger": {
324    "stepping_granularity": "instruction"
325  }
326}
327```
328
329### Save Breakpoints
330
331- Description: Whether the breakpoints should be saved across Zed sessions.
332- Default: true
333- Setting: debugger.save_breakpoints
334
335**Options**
336
337`boolean` values
338
339```json
340{
341  "debugger": {
342    "save_breakpoints": true
343  }
344}
345```
346
347### Button
348
349- Description: Whether the button should be displayed in the debugger toolbar.
350- Default: true
351- Setting: debugger.show_button
352
353**Options**
354
355`boolean` values
356
357```json
358{
359  "debugger": {
360    "show_button": true
361  }
362}
363```
364
365### Timeout
366
367- Description: Time in milliseconds until timeout error when connecting to a TCP debug adapter.
368- Default: 2000
369- Setting: debugger.timeout
370
371**Options**
372
373`integer` values
374
375```json
376{
377  "debugger": {
378    "timeout": 3000
379  }
380}
381```
382
383### Log Dap Communications
384
385- Description: Whether to log messages between active debug adapters and Zed. (Used for DAP development)
386- Default: false
387- Setting: debugger.log_dap_communications
388
389**Options**
390
391`boolean` values
392
393```json
394{
395  "debugger": {
396    "log_dap_communications": true
397  }
398}
399```
400
401### Format Dap Log Messages
402
403- Description: Whether to format DAP messages when adding them to the debug adapter logger. (Used for DAP development)
404- Default: false
405- Setting: debugger.format_dap_log_messages
406
407**Options**
408
409`boolean` values
410
411```json
412{
413  "debugger": {
414    "format_dap_log_messages": true
415  }
416}
417```
418
419## Theme
420
421The Debugger supports the following theme options:
422
423**debugger.accent**: Color used to accent breakpoint & breakpoint-related symbols
424**editor.debugger_active_line.background**: Background color of active debug line