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)). It's also recommended to use
17   `-O opt-level=0` for better inspection of local variables if desired.
18
193. Use a supported debugger:
20
21    ```sh
22    lldb -- wasmtime run -D debug-info foo.wasm
23    ```
24    ```sh
25    gdb --args wasmtime run -D debug-info -O opt-level=0 foo.wasm
26    ```
27
28If you run into trouble, the following discussions might help:
29
30- On MacOS with LLDB you may need to run: `settings set
31  plugin.jit-loader.gdb.enable on`
32  ([#1953](https://github.com/bytecodealliance/wasmtime/issues/1953))
33
34- With LLDB, call `__vmctx.set()` to set the current context before calling any
35  dereference operators
36  ([#1482](https://github.com/bytecodealliance/wasmtime/issues/1482)):
37  ```sh
38  (lldb) p __vmctx->set()
39  (lldb) p *foo
40  ```
41
42- The address of the start of instance memory can be found in `__vmctx->memory`
43
44- On Windows you may experience degraded WASM compilation throughput due to the
45  enablement of additional native heap checks when under the debugger by default.
46  You can set the environment variable `_NO_DEBUG_HEAP` to `1` to disable them.
47