Mozilla recently demonstrated debugging of WebAssembly binaries outside the browser, using standard debuggers like GDB and LLDB. Debugging WebAssembly code in the same execution environment used in production allows developers to catch and diagnose bugs that may not arise in a native build of the same code.
WebAssembly, in connection with WASI, has recently made strides to be used outside of the browser, and realize the Write Once, Run Anywhere promise. While running WebAssembly programs outside the browser is already possible, in particular with wasmtime, the debugging story presents some difficulties. While WASI allows developers to use console logging to report on the execution of the program, it was not possible to debug the original source. Taking the example of a Rust source compiled to WebAssembly, rustwasm documentation explains the issue:
Debuggers currently provide limited utility, and we end up stepping through raw WebAssembly instructions emitted by the compiler, rather than the Rust source text we authored.
Source-level debugging of .wasm files using traditional tools like GDB and LLDB is now possible. In a recently published screencast, Mozilla illustrates the debugging with LLDB of a Rust-generated WebAssembly program that implements a solution to the FizzBuzz problem. The screencast first showcases compiling Rust code with cargo to WebAssembly, and running the generated wasm code with wasmtime. The screencast continues with instrumenting the wasm code with debugging information, using LLDB:
lldb -- wasmtime -g target/wasm32-wasi/debug/fizz.wasm
Once this is done, developers can use breakpoints (for instance breakpoint set -name fizzbuzz), source-level navigation, inspect and modify variables during the interrupted execution of the program, view and navigate stack frames, and perform other typical debugging functions with the command line interface or the graphical user interface of LLDB:
Mozilla explains how source-level debugging may help WebAssembly developers catch otherwise obfuscated bugs:
Wasmtime’s debugging support makes it easier to catch and diagnose bugs that may not arise in a native build of the same code. For example, the WebAssembly System Interface(WASI) treats filesystem access more strictly than traditional Unix-style permissions. This could create issues that only manifest in WebAssembly runtimes.
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. The LLDB project builds on libraries provided by LLVM and provides a native debugger.
GDB (GNU Project debugger) is a debugger which supports the following languages: C++, Rust, Go, Objective-C, Ada, Assembly, C, D, Fortran, OpenCL, Modula-2, and Pascal.
WASI (WebAssembly System Interface) is a modular system interface for WebAssembly focused on security and portability, which is on a standardization path. WASI aims at enabling developers to run WebAssembly programs on any devices, computers, or operating systems.
Wasmtime is a standalone JIT-style runtime for WebAssembly. The Wasmtime runtime’s tutorial contains examples for how to target WASI from C and Rust. The resulting .wasm modules can be run in any WASI-compliant runtime, such as Wasmtime or Fastly’s Lucet.