You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Blog: Debugging wasm with VSCode](https://bytecodealliance.github.io/wamr.dev/blog/debugging-wasm-with-vscode/)
6
-
7
-
WAMR supports source level debugging based on DWARF (normally used in C/C++/Rust), source map (normally used in AssemblyScript) is not supported.
8
-
9
-
**The lldb's ability to debug wasm application is based on the patch [Add class WasmProcess for WebAssembly debugging](https://reviews.llvm.org/D78801). Thanks very much to the author @paolosev for such a great work!**
10
-
11
3
## Build wasm application with debug information
12
4
To debug your application, you need to compile them with debug information. You can use `-g` option when compiling the source code if you are using wasi-sdk (also work for emcc and rustc):
13
5
```bash
@@ -20,205 +12,9 @@ llvm-dwarfdump-12 test.wasm
20
12
```
21
13
22
14
## Debugging with interpreter
23
-
1. Install dependent libraries
24
-
```bash
25
-
apt update && apt install cmake make g++ libxml2-dev -y
26
-
```
27
-
28
-
2. Build iwasm with source debugging feature
29
-
```bash
30
-
cd${WAMR_ROOT}/product-mini/platforms/linux
31
-
mkdir build &&cd build
32
-
cmake .. -DWAMR_BUILD_DEBUG_INTERP=1
33
-
make
34
-
```
35
-
> Note: On MacOS M1 environment, pass the additional `-DWAMR_DISABLE_HW_BOUND_CHECK=1` cmake configuration.
36
-
37
-
3. Execute iwasm with debug engine enabled
38
-
```bash
39
-
iwasm -g=127.0.0.1:1234 test.wasm
40
-
# Use port = 0 to allow a random assigned debug port
3. Enable source debugging features during building
205
-
206
-
You can use `-DWAMR_BUILD_DEBUG_INTERP=1` during cmake configuration
207
-
208
-
Or you can set it directly in`cmake` files:
209
-
``` cmake
210
-
set (WAMR_BUILD_DEBUG_INTERP 1)
211
-
```
212
-
213
-
### Attentions
214
-
- Debugging `multi-thread wasm module` is not supported, if your wasm module use pthread APIs (see [pthread_library.md](./pthread_library.md)), or the embedder use `wasm_runtime_spawn_thread` to create new wasm threads, then there may be **unexpected behaviour** during debugging.
215
-
216
-
> Note: This attention is about "wasm thread" rather than native threads. Executing wasm functions in several different native threads will **not** affect the normal behaviour of debugging feature.
217
-
218
-
- When using source debugging features, **don't** create multiple `wasm_instance` from the same `wasm_module`, because the debugger may change the bytecode (set/unset breakpoints) of the `wasm_module`. If you do need several instance from the same bytecode, you need to copy the bytecode to a new butter, then load a new `wasm_module`, and then instantiate the new wasm module to get the new instance.
219
-
220
-
- If you are running `lldb` on non-linux platforms, please use `platform select remote-linux` command in lldb before connecting to the runtime:
221
-
```
222
-
(lldb) platform select remote-linux
223
-
(lldb) process connect -p wasm connect://127.0.0.1:1234
224
-
```
20
+
See [Debuggging with AOT](source_debugging_aot.md).
0 commit comments