0e4c4799b1
Update the `addr2line` script so that:
- line info is printed in a more convenient format, e.g.
```
0: c
at wasm-micro-runtime/test-tools/addr2line/trap.c:5:1
1: b
at wasm-micro-runtime/test-tools/addr2line/trap.c:11:12
2: a
at wasm-micro-runtime/test-tools/addr2line/trap.c:17:12
```
similar to how Rust prints stack traces when there's a panic. In an IDE, the user
can conveniently click on the printed path and be redirected to the file line.
- a new `--no-addr` argument can be provided to the script
It can be used in fast interpreter mode (that is not supported by the script otherwise)
or with older wamr versions (where the stack trace only had the function index info
and not the function address). In that case, `wasm-objdump` is used to get the function
name from the index and `llvm-dwarfdump` to obtain the location info (where the line
refers to the start of the function).
|
||
|---|---|---|
| .. | ||
| wasm-apps | ||
| CMakeLists.txt | ||
| README.md | ||
| symbolicate.sh | ||
"debug-tools" sample introduction
Tool to symoblicate stack traces. When using wasm in production, debug info are usually stripped using tools like wasm-opt, to decrease the binary size. If a corresponding unstripped wasm file is kept, location information (function, file, line, column) can be retrieved from the stripped stack trace.
Build and run the sample
Generate the stack trace
Build iwasm with WAMR_BUILD_DUMP_CALL_STACK=1 and WAMR_BUILD_FAST_INTERP=0 and the wasm file with debug info (e.g. clang -g). As it is done in CMakeLists.txt and wasm-apps/CMakeLists.txt (look for addr2line):
$ mkdir build && cd build
$ cmake ..
$ make
$ ./iwasm wasm-apps/trap.wasm
The output should be something like
#00: 0x0159 - $f5
#01: 0x01b2 - $f6
#02: 0x0200 - $f7
#03: 0x026b - $f8
#04: 0x236b - $f15
#05: 0x011f - _start
Exception: unreachable
Copy the stack trace printed to stdout into a separate file (call_stack.txt):
$ ./iwasm wasm-apps/trap.wasm | grep "#" > call_stack.txt
Same for AOT. The AOT binary has to be generated using the --enable-dump-call-stack option of wamrc, as in CMakeLists.txt. Then run:
$ ./iwasm wasm-apps/trap.aot | grep "#" > call_stack.txt
Symbolicate the stack trace
Run the addr2line script to symbolicate the stack trace:
$ python3 ../../../test-tools/addr2line/addr2line.py \
--wasi-sdk /opt/wasi-sdk \
--wabt /opt/wabt \
--wasm-file wasm-apps/trap.wasm \
call_stack.txt
The output should be something like:
0: c
at wasm-micro-runtime/samples/debug-tools/wasm-apps/trap.c:5:1
1: b
at wasm-micro-runtime/samples/debug-tools/wasm-apps/trap.c:11:12
2: a
at wasm-micro-runtime/samples/debug-tools/wasm-apps/trap.c:17:12
3: main
at wasm-micro-runtime/samples/debug-tools/wasm-apps/trap.c:24:5
4: <unknown>
at unknown:?:?
5: _start
If WAMR is run in fast interpreter mode (WAMR_BUILD_FAST_INTERP=1), addresses in the stack trace cannot be tracked back to location info.
If WAMR <= 1.3.2 is used, the stack trace does not contain addresses.
In those two cases, run the script with --no-addr: the line info returned refers to the start of the function
$ python3 ../../../test-tools/addr2line/addr2line.py \
--wasi-sdk /opt/wasi-sdk \
--wabt /opt/wabt \
--wasm-file wasm-apps/trap.wasm \
call_stack.txt --no-addr