Debugging WebAssembly? Put some Whamm on it!

TL;DR

Whamm tackles fragmentation and overhead in WebAssembly dynamic analysis by introducing a declarative instrumentation language that works across both bytecode rewriting and engine‑level monitoring. It details two high‑performance realizations, a rewriting path using the Seal library and an engine interface where monitors are loaded as Wasm modules, and it demonstrates substantial compiler and engine optimizations (e.g., constant propagation, predicate splitting, trampolines, JIT inlining). The contributions include an expressive DSL with storage classes and libraries, a practical implementation in Rust, and an empirical evaluation showing expressiveness and competitive performance against existing frameworks. The work advances practical WASM instrumentation by enabling portable, composable monitors that can run across engines with minimal overhead and easy library integration.

Abstract

Debugging and monitoring programs are integral to engineering and deploying software. Dynamic analyses monitor applications through source code or IR injection, machine code or bytecode rewriting, and virtual machine or direct hardware support. While these techniques are viable within their respective domains, common tooling across techniques is rare, leading to fragmentation of skills, duplicated efforts, and inconsistent feature support. We address this problem in the WebAssembly ecosystem with Whamm, a declarative instrumentation DSL for WebAssembly that abstracts above the instrumentation strategy, leveraging bytecode rewriting and engine support as available. Whamm solves three problems: 1) tooling fragmentation, 2) prohibitive instrumentation overhead of general-purpose frameworks, and 3) tedium of tailoring low-level high-performance mechanisms. Whamm provides fully-programmable instrumentation with declarative match rules, static and dynamic predication, automatic state reporting, and user library support, while achieving high performance through compiler and engine optimizations. At the back end, Whamm provides instrumentation to a Wasm engine as Wasm code, reusing existing engine optimizations and unlocking new ones, most notably intrinsification, to minimize overhead. In particular, explicitly requesting program state in match rules, rather than reflection, enables the engine to efficiently bundle arguments and even inline compiled probe logic. Whamm streamlines the tooling effort, as its bytecode-rewriting target can run instrumented programs everywhere, lowering fragmentation and advancing the state of the art for engine support. We evaluate Whamm with case studies of non-trivial monitors and show it is expressive, powerful, and efficient.

Figures (6)

• Figure 1: Contribution map of this paper. We have designed and implemented a new expressive DSL (codenamed Whamm) for concise instrumentation of Wasm applications with support for extensible libraries. It features an optimizing compiler that targets either rewriting (which injects bytecode into the application and can run anywhere) or a new engine monitoring interface (codenamed whamm) with high performance.
• Figure 2: Directives in Whamm consist of a triple of a match rule that includes bounds on typed arguments, an optional predicate, and consequent actions.
• Figure 3: Each step of static instrumentation with Whamm when targeting the bytecode rewriting. In (0) the application module is visited to find event matches, then at a match, (1) the variables referenced by the probe body are saved, (2) the probe body is compiled to WebAssembly and inlined, and (3) the stack is restored to its original state for the original application bytecode.
• Figure 4: Example of compiling Whamm to the engine target whamm. The monitor script (0) is compiled to a complete Wasm module that encodes match rules in the names of exported functions. At load time, the engine loads the monitor module and (1) applies the match rules to the application-under-observation. At runtime (2), when a probed location is reached, the engine will (3) bundle the requested data and invoke the probe callback.
• Figure 5: Illustrates the whamm engine interface. Wasm monitor modules encode directive match rules, type bounds and predicates into exported functions, expressing where to insert probes declaratively. The match time callback readies instrumentation state for each match location in the program. The variable request(s) or whamm-params, instruct the engine on the program state to pass during callback invocation.