You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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:
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:
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
# 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
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: