wabt

The WebAssembly Binary Toolkit

6,727

684

6,727

150

View on GitHub

Top Related Projects

wasmtime

15,089

A fast and secure runtime for WebAssembly

wasmer

18,439

🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten

emscripten

25,606

Emscripten: An LLVM-to-WebAssembly Compiler

assemblyscript

16,749

A TypeScript-like language for WebAssembly.

binaryen

7,403

Optimizer and compiler/toolchain library for WebAssembly

wasm-tools

1,282

CLI and Rust libraries for low-level manipulation of WebAssembly modules

Quick Overview

WABT (WebAssembly Binary Toolkit) is a suite of tools for working with WebAssembly. It includes utilities for converting between WebAssembly text format (WAT) and binary format (WASM), as well as tools for inspecting, validating, and manipulating WebAssembly modules.

Pros

Comprehensive toolkit for WebAssembly development and debugging
Supports both text and binary formats of WebAssembly
Actively maintained and regularly updated
Cross-platform compatibility (works on Windows, macOS, and Linux)

Cons

Requires compilation from source, which may be challenging for some users
Limited documentation for advanced use cases
Steep learning curve for users unfamiliar with WebAssembly concepts

Getting Started

To get started with WABT, follow these steps:

Clone the repository:

git clone --recursive https://github.com/WebAssembly/wabt
cd wabt

Create and enter the build directory:
```
mkdir build
cd build
```
Configure and build the project:
```
cmake ..
cmake --build .
```
The built tools will be in the build directory. You can now use them, for example:
```
./wat2wasm input.wat -o output.wasm
```

This will convert a WebAssembly text file (input.wat) to a binary WebAssembly file (output.wasm).

Competitor Comparisons

wasmtime

15,089

A fast and secure runtime for WebAssembly

Pros of wasmtime

More comprehensive WebAssembly runtime with JIT compilation
Supports WASI (WebAssembly System Interface) for system-level interactions
Actively developed with frequent updates and broader feature set

Cons of wasmtime

Larger codebase and more complex architecture
Potentially higher resource usage due to JIT compilation
Steeper learning curve for beginners

Code comparison

wabt (text to binary conversion):

wasm_parse_file(filename, &parser, 1);
WasmResult result = wasm_write_binary_file(out_filename, &parser.module,
                                           write_debug_names);

wasmtime (running a WebAssembly module):

let engine = Engine::default();
let module = Module::from_file(&engine, "example.wasm")?;
let instance = Instance::new(&mut store, &module, &[])?;

Summary

wasmtime is a more feature-rich WebAssembly runtime with WASI support and JIT compilation, while wabt focuses on WebAssembly toolkit functionality like text-to-binary conversion. wasmtime offers a broader range of capabilities but may be more complex for simple tasks. wabt is lighter and more straightforward for basic WebAssembly operations but lacks advanced runtime features.

wasmer

18,439

🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten

Pros of Wasmer

Provides a complete WebAssembly runtime environment, allowing execution of WebAssembly modules in various contexts
Supports multiple backends (LLVM, Cranelift, Singlepass) for optimized performance
Offers language integrations for Python, Ruby, PHP, and more

Cons of Wasmer

Larger project scope and complexity compared to WABT's focused tooling approach
May have a steeper learning curve for users only interested in basic WebAssembly manipulation

Code Comparison

WABT (C++):

#include "src/binary-reader.h"
#include "src/error-formatter.h"

void ReadModule(const std::string& filename) {
  // WABT-specific module reading logic
}

Wasmer (Rust):

use wasmer::{Store, Module, Instance};

fn run_wasm_module(wasm_bytes: &[u8]) -> Result<(), Box<dyn std::error::Error>> {
    let store = Store::default();
    let module = Module::new(&store, wasm_bytes)?;
    let instance = Instance::new(&module, &[])?;
    // Wasmer-specific instance execution logic
    Ok(())
}

The code snippets highlight the different focus areas: WABT on low-level WebAssembly manipulation, and Wasmer on runtime execution and integration.

emscripten

25,606

Emscripten: An LLVM-to-WebAssembly Compiler

Pros of Emscripten

Comprehensive toolchain for compiling C/C++ to WebAssembly
Extensive standard library support and JavaScript interoperability
Active development and large community support

Cons of Emscripten

Steeper learning curve due to its complexity
Larger output size compared to hand-written WebAssembly
Can be overkill for simple projects

Code Comparison

Emscripten (C++ to WebAssembly):

#include <emscripten.h>
#include <iostream>

EMSCRIPTEN_KEEPALIVE
int add(int a, int b) {
    return a + b;
}

WABT (WebAssembly Text Format):

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add)))

Emscripten provides a more familiar C++ environment with automatic compilation to WebAssembly, while WABT requires writing WebAssembly directly in its text format. Emscripten is better suited for large-scale projects and existing C/C++ codebases, whereas WABT is more lightweight and offers finer control over the resulting WebAssembly module.

assemblyscript

16,749

A TypeScript-like language for WebAssembly.

Pros of AssemblyScript

Familiar TypeScript-like syntax, making it easier for JavaScript developers to adopt
Compiles directly to WebAssembly, offering a more streamlined development process
Provides a standard library and built-in types optimized for WebAssembly

Cons of AssemblyScript

Limited ecosystem compared to more established WebAssembly tools
May not be suitable for low-level, performance-critical applications that require fine-grained control

Code Comparison

AssemblyScript:

export function add(a: i32, b: i32): i32 {
  return a + b;
}

WABT (WebAssembly Text Format):

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add)))

AssemblyScript offers a more familiar syntax for JavaScript developers, while WABT provides a lower-level representation closer to the WebAssembly binary format. AssemblyScript abstracts away some of the complexities of WebAssembly, making it more accessible for web developers. However, WABT offers more direct control over the generated WebAssembly code, which can be beneficial for performance-critical applications or when working with existing WebAssembly modules.

binaryen

7,403

Optimizer and compiler/toolchain library for WebAssembly

Pros of Binaryen

More comprehensive optimization toolchain for WebAssembly
Supports advanced features like SIMD and multi-threading
Offers a C API for easier integration into other projects

Cons of Binaryen

Steeper learning curve due to more complex functionality
Larger codebase, potentially slower compilation times
May be overkill for simpler WebAssembly projects

Code Comparison

Binaryen (C++ API):

Module module;
Expression* add = builder.makeAdd(
  builder.makeConst(Literal(int32_t(1))),
  builder.makeConst(Literal(int32_t(2)))
);

WABT (C API):

wasm_opcode_t opcodes[] = {WASM_OP_I32_CONST, WASM_OP_I32_CONST, WASM_OP_I32_ADD};
uint32_t values[] = {1, 2};
wasm_write_opcode_array(&ctx, opcodes, 3);
wasm_write_u32v(&ctx, values, 2);

Summary

Binaryen offers more advanced optimization and features for WebAssembly, making it suitable for complex projects. WABT provides a simpler, more straightforward approach to WebAssembly tooling. Choose Binaryen for comprehensive optimization and advanced features, or WABT for basic WebAssembly manipulation and a gentler learning curve.

wasm-tools

1,282

CLI and Rust libraries for low-level manipulation of WebAssembly modules

Pros of wasm-tools

Written in Rust, offering better memory safety and performance
More actively maintained with frequent updates
Supports newer WebAssembly features like multi-value returns and bulk memory operations

Cons of wasm-tools

Smaller ecosystem and less widespread adoption compared to wabt
Steeper learning curve for developers not familiar with Rust
Some tools and features are still in experimental stages

Code Comparison

wabt (C++):

#include <cstdio>
#include "src/binary-reader.h"
#include "src/error-formatter.h"

void ReadModule(const std::string& filename) {
  // Implementation details
}

wasm-tools (Rust):

use wasm_tools::parser::Parser;
use wasm_tools::binary::read::ReadBinary;

fn read_module(filename: &str) -> Result<(), Box<dyn std::error::Error>> {
    // Implementation details
}

Both repositories provide tools for working with WebAssembly binaries, but they differ in their implementation languages and feature sets. wabt is more established and widely used, while wasm-tools offers newer features and potential performance benefits. The choice between them depends on specific project requirements and developer preferences.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

WABT: The WebAssembly Binary Toolkit

WABT (we pronounce it "wabbit") is a suite of tools for WebAssembly, including:

wat2wasm: translate from WebAssembly text format to the WebAssembly binary format
wasm2wat: the inverse of wat2wasm, translate from the binary format back to the text format (also known as a .wat)
wasm-objdump: print information about a wasm binary. Similiar to objdump.
wasm-interp: decode and run a WebAssembly binary file using a stack-based interpreter
wasm-decompile: decompile a wasm binary into readable C-like syntax.
wat-desugar: parse .wat text form as supported by the spec interpreter (s-expressions, flat syntax, or mixed) and print "canonical" flat format
wasm2c: convert a WebAssembly binary file to a C source and header
wasm-strip: remove sections of a WebAssembly binary file
wasm-validate: validate a file in the WebAssembly binary format
wast2json: convert a file in the wasm spec test format to a JSON file and associated wasm binary files
wasm-stats: output stats for a module
spectest-interp: read a Spectest JSON file, and run its tests in the interpreter

These tools are intended for use in (or for development of) toolchains or other systems that want to manipulate WebAssembly files. Unlike the WebAssembly spec interpreter (which is written to be as simple, declarative and "speccy" as possible), they are written in C/C++ and designed for easier integration into other systems. Unlike Binaryen these tools do not aim to provide an optimization platform or a higher-level compiler target; instead they aim for full fidelity and compliance with the spec (e.g. 1:1 round-trips with no changes to instructions).

Online Demos

Wabt has been compiled to JavaScript via emscripten. Some of the functionality is available in the following demos:

Supported Proposals

Proposal: Name and link to the WebAssembly proposal repo
flag: Flag to pass to the tool to enable/disable support for the feature
default: Whether the feature is enabled by default
binary: Whether wabt can read/write the binary format
text: Whether wabt can read/write the text format
validate: Whether wabt can validate the syntax
interpret: Whether wabt can execute these operations in wasm-interp or spectest-interp
wasm2c: Whether wasm2c supports these operations

Proposal	flag	default	binary	text	validate	interpret	wasm2c
exception handling	`--enable-exceptions`		â	â	â	â	â
mutable globals	`--disable-mutable-globals`	â	â	â	â	â	â
nontrapping float-to-int conversions	`--disable-saturating-float-to-int`	â	â	â	â	â	â
sign extension	`--disable-sign-extension`	â	â	â	â	â	â
simd	`--disable-simd`	â	â	â	â	â	â
threads	`--enable-threads`		â	â	â	â
multi-value	`--disable-multi-value`	â	â	â	â	â	â
tail-call	`--enable-tail-call`		â	â	â	â	â
bulk memory	`--disable-bulk-memory`	â	â	â	â	â	â
reference types	`--disable-reference-types`	â	â	â	â	â	â
annotations	`--enable-annotations`			â
memory64	`--enable-memory64`		â	â	â	â	â
multi-memory	`--enable-multi-memory`		â	â	â	â	â
extended-const	`--enable-extended-const`		â	â	â	â	â
relaxed-simd	`--enable-relaxed-simd`		â	â	â	â

Cloning

Clone as normal, but don't forget to get the submodules as well:

$ git clone --recursive https://github.com/WebAssembly/wabt
$ cd wabt
$ git submodule update --init

This will fetch the testsuite and gtest repos, which are needed for some tests.

Building using CMake directly (Linux and macOS)

You'll need CMake. You can then run CMake, the normal way:

$ mkdir build
$ cd build
$ cmake ..
$ cmake --build .

This will produce build files using CMake's default build generator. Read the CMake documentation for more information.

NOTE: You must create a separate directory for the build artifacts (e.g. build above). Running cmake from the repo root directory will not work since the build produces an executable called wasm2c which conflicts with the wasm2c directory.

Building using the top-level `Makefile` (Linux and macOS)

NOTE: Under the hood, this uses make to run CMake, which then calls ninja to perform that actual build. On some systems (typically macOS), this doesn't build properly. If you see these errors, you can build using CMake directly as described above.

You'll need CMake and Ninja. If you just run make, it will run CMake for you, and put the result in out/clang/Debug/ by default:

Note: If you are on macOS, you will need to use CMake version 3.2 or higher

$ make

This will build the default version of the tools: a debug build using the Clang compiler.

There are many make targets available for other configurations as well. They are generated from every combination of a compiler, build type and configuration.

compilers: gcc, clang, gcc-i686, emscripten
build types: debug, release
configurations: empty, asan, msan, lsan, ubsan, fuzz, no-tests

They are combined with dashes, for example:

$ make clang-debug
$ make gcc-i686-release
$ make clang-debug-lsan
$ make gcc-debug-no-tests

Building (Windows)

You'll need CMake. You'll also need Visual Studio (2015 or newer) or MinGW.

Note: Visual Studio 2017 and later come with CMake (and the Ninja build system) out of the box, and should be on your PATH if you open a Developer Command prompt. See https://aka.ms/cmake for more details.

You can run CMake from the command prompt, or use the CMake GUI tool. See Running CMake for more information.

When running from the commandline, create a new directory for the build artifacts, then run cmake from this directory:

> cd [build dir]
> cmake [wabt project root] -DCMAKE_BUILD_TYPE=[config] -DCMAKE_INSTALL_PREFIX=[install directory] -G [generator]

The [config] parameter should be a CMake build type, typically DEBUG or RELEASE.

The [generator] parameter should be the type of project you want to generate, for example "Visual Studio 14 2015". You can see the list of available generators by running cmake --help.

To build the project, you can use Visual Studio, or you can tell CMake to do it:

> cmake --build [wabt project root] --config [config] --target install

This will build and install to the installation directory you provided above.

So, for example, if you want to build the debug configuration on Visual Studio 2015:

> mkdir build
> cd build
> cmake .. -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_INSTALL_PREFIX=..\ -G "Visual Studio 14 2015"
> cmake --build . --config DEBUG --target install

Adding new keywords to the lexer

If you want to add new keywords, you'll need to install gperf. Before you upload your PR, please run make update-gperf to update the prebuilt C++ sources in src/prebuilt/.

Running wat2wasm

Some examples:

# parse test.wat and write to .wasm binary file with the same name
$ bin/wat2wasm test.wat

# parse test.wat and write to binary file test.wasm
$ bin/wat2wasm test.wat -o test.wasm

# parse spec-test.wast, and write verbose output to stdout (including the
# meaning of every byte)
$ bin/wat2wasm spec-test.wast -v

You can use --help to get additional help:

$ bin/wat2wasm --help

Or try the online demo.

Running wasm2wat

Some examples:

# parse binary file test.wasm and write text file test.wat
$ bin/wasm2wat test.wasm -o test.wat

# parse test.wasm and write test.wat
$ bin/wasm2wat test.wasm -o test.wat

You can use --help to get additional help:

$ bin/wasm2wat --help

Or try the online demo.

Running wasm-interp

Some examples:

# parse binary file test.wasm, and type-check it
$ bin/wasm-interp test.wasm

# parse test.wasm and run all its exported functions
$ bin/wasm-interp test.wasm --run-all-exports

# parse test.wasm, run the exported functions and trace the output
$ bin/wasm-interp test.wasm --run-all-exports --trace

# parse test.json and run the spec tests
$ bin/wasm-interp test.json --spec

# parse test.wasm and run all its exported functions, setting the value stack
# size to 100 elements
$ bin/wasm-interp test.wasm -V 100 --run-all-exports

You can use --help to get additional help:

$ bin/wasm-interp --help

Running wast2json

See wast2json.md.

Running wasm-decompile

For example:

# parse binary file test.wasm and write text file test.dcmp
$ bin/wasm-decompile test.wasm -o test.dcmp

You can use --help to get additional help:

$ bin/wasm-decompile --help

See decompiler.md for more information on the language being generated.

Running wasm2c

See wasm2c.md

Running the test suite

See test/README.md.

Sanitizers

To build with the LLVM sanitizers, append the sanitizer name to the target:

$ make clang-debug-asan
$ make clang-debug-msan
$ make clang-debug-lsan
$ make clang-debug-ubsan

There are configurations for the Address Sanitizer (ASAN), Memory Sanitizer (MSAN), Leak Sanitizer (LSAN) and Undefined Behavior Sanitizer (UBSAN). You can read about the behaviors of the sanitizers in the link above, but essentially the Address Sanitizer finds invalid memory accesses (use after free, access out-of-bounds, etc.), Memory Sanitizer finds uses of uninitialized memory, the Leak Sanitizer finds memory leaks, and the Undefined Behavior Sanitizer finds undefined behavior (surprise!).

Typically, you'll just want to run all the tests for a given sanitizer:

$ make test-asan

You can also run the tests for a release build:

$ make test-clang-release-asan
...

The GitHub actions bots run all of these tests (and more). Before you land a change, you should run them too. One easy way is to use the test-everything target:

$ make test-everything

Fuzzing

To build using the LLVM fuzzer support, append fuzz to the target:

$ make clang-debug-fuzz

This will produce a wasm2wat_fuzz binary. It can be used to fuzz the binary reader, as well as reproduce fuzzer errors found by oss-fuzz.

$ out/clang/Debug/fuzz/wasm2wat_fuzz ...

See the libFuzzer documentation for more information about how to use this tool.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Getting Started

Competitor Comparisons

Pros of wasmtime

Cons of wasmtime

Code comparison

Summary

Pros of Wasmer

Cons of Wasmer

Code Comparison

Pros of Emscripten

Cons of Emscripten

Code Comparison

Pros of AssemblyScript

Cons of AssemblyScript

Code Comparison

Pros of Binaryen

Cons of Binaryen

Code Comparison

Summary

Pros of wasm-tools

Cons of wasm-tools

Code Comparison

Convert designs to code with AI

README

WABT: The WebAssembly Binary Toolkit

Online Demos

Supported Proposals

Cloning

Building using CMake directly (Linux and macOS)

Building using the top-level Makefile (Linux and macOS)

Building (Windows)

Adding new keywords to the lexer

Running wat2wasm

Running wasm2wat

Running wasm-interp

Running wast2json

Running wasm-decompile

Running wasm2c

Running the test suite

Sanitizers

Fuzzing

Top Related Projects

Convert designs to code with AI

Building using the top-level `Makefile` (Linux and macOS)