mirror of https://github.com/encounter/wasmtime.git synced 2026-03-30 11:42:15 -07:00

Files

T

SingleAccretion 9377dfd7b8 Add a note about _NO_DEBUG_HEAP to the debugging document (#6963 )

While this is not at all WASM-specific, it is somewhat rare that
LLDB is used for native debugging on Windows, so the cause of
the slowdown on the order of 50x may not be immediately obvious.

2023-09-05 14:02:12 +00:00

1.3 KiB

Raw Blame History

Debugging WebAssembly

The following steps describe a common way to debug a WebAssembly module in Wasmtime:

Compile your WebAssembly with debug info enabled, usually -g; for example:
```
clang foo.c -g -o foo.wasm
```
Run Wasmtime with the debug info enabled; this is -g from the CLI and Config::debug_info(true) in an embedding (e.g. see debugging in a Rust embedding)

Use a supported debugger:

lldb -- wasmtime run -g foo.wasm

gdb --args wasmtime run -g foo.wasm

If you run into trouble, the following discussions might help:

On MacOS with LLDB you may need to run: settings set plugin.jit-loader.gdb.enable on (#1953)
With LLDB, call __vmctx.set() to set the current context before calling any dereference operators (#1482):
```
(lldb) p __vmctx->set()
(lldb) p *foo
```
The address of the start of instance memory can be found in __vmctx->memory
On Windows you may experience degraded WASM compilation throughput due to the enablement of additional native heap checks when under the debugger by default. You can set the environment variable _NO_DEBUG_HEAP to 1 to disable them.

1.3 KiB Raw Blame History

Debugging WebAssembly

1.3 KiB

Raw Blame History