1# Debugging with `gdb` and `lldb`
2
3The following steps describe how to use `gdb` or `lldb` to debug both the Wasm
4guest and the host (i.e. the Wasmtime CLI or your Wasmtime-embedding program) at
5the same time:
6
71. Compile your WebAssembly with debug info enabled, usually `-g`; for
8   example:
9
10    ```sh
11    clang foo.c -g -o foo.wasm
12    ```
13
142. Run Wasmtime with the debug info enabled; this is `-D debug-info` from the
15   CLI and `Config::debug_info(true)` in an embedding (e.g. see [debugging in a
16   Rust embedding](./examples-rust-debugging.md))
17
183. Use a supported debugger:
19
20    ```sh
21    lldb -- wasmtime run -D debug-info foo.wasm
22    ```
23    ```sh
24    gdb --args wasmtime run -D debug-info foo.wasm
25    ```
26
27If you run into trouble, the following discussions might help:
28
29- On MacOS with LLDB you may need to run: `settings set
30  plugin.jit-loader.gdb.enable on`
31  ([#1953](https://github.com/bytecodealliance/wasmtime/issues/1953))
32
33- With LLDB, call `__vmctx.set()` to set the current context before calling any
34  dereference operators
35  ([#1482](https://github.com/bytecodealliance/wasmtime/issues/1482)):
36  ```sh
37  (lldb) p __vmctx->set()
38  (lldb) p *foo
39  ```
40
41- The address of the start of instance memory can be found in `__vmctx->memory`
42
43- On Windows you may experience degraded WASM compilation throughput due to the
44  enablement of additional native heap checks when under the debugger by default.
45  You can set the environment variable `_NO_DEBUG_HEAP` to `1` to disable them.
46