wasm-micro-runtime/samples/debug-tools
liang.he 202abc1937
Small enhancement on addr2line.py (#3276)
- If can't parse function name with dwarf information, use "name
  section" instead
- Add introduction about using custom section
2024-04-04 18:32:53 +08:00
..
wasm-apps Get location info from function indexes in addr2line script (#3206) 2024-03-08 10:20:04 +08:00
CMakeLists.txt Get location info from function indexes in addr2line script (#3206) 2024-03-08 10:20:04 +08:00
README.md Small enhancement on addr2line.py (#3276) 2024-04-04 18:32:53 +08:00
symbolicate.sh Get location info from function indexes in addr2line script (#3206) 2024-03-08 10:20:04 +08:00

"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: __main_void
        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

Another approach

If the wasm file is with "name" section, it is able to output function name in the stack trace. To achieve that, need to enable WAMR_BUILD_LOAD_CUSTOM_SECTION and WAMR_BUILD_CUSTOM_NAME_SECTION. If using .aot file, need to add --emit-custom-sections=name into wamrc command line options.

Then the output should be something like

#00: 0x0159 - c
#01: 0x01b2 - b
#02: 0x0200 - a
#03: 0x026b - main
#04: 0x236b - __main_void
#05: 0x011f - _start

Exception: unreachable

Also, it is able to use addr2line.py to add file and line info to the stack trace.