代码拉取完成，页面将自动刷新
WABT (we pronounce it "wabbit") is a suite of tools for WebAssembly, including:
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).
Wabt has been compiled to JavaScript via emscripten. Some of the functionality is available in the following demos:
wasm-interp or spectest-interp
| Proposal | flag | default | binary | text | validate | interpret |
|---|---|---|---|---|---|---|
| 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 | --enable-simd |
✓ | ✓ | ✓ | ✓ | |
| threads | --enable-threads |
✓ | ✓ | ✓ | ✓ | |
| multi-value | --disable-multi-value |
✓ | ✓ | ✓ | ✓ | ✓ |
| tail-call | --enable-tail-call |
✓ | ✓ | ✓ | ✓ | |
| bulk memory | --enable-bulk-memory |
✓ | ✓ | ✓ | ✓ | |
| reference types | --enable-reference-types |
✓ | ✓ | ✓ | ✓ | |
| annotations | --enable-annotations |
✓ | ||||
| memory64 | --enable-memory64 |
Clone as normal, but don't forget to get the submodules as well:
$ git clone --recursive https://github.com/WebAssembly/wabt
$ cd wabt
This will fetch the testsuite and gtest repos, which are needed for some tests.
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.
Makefile (Linux and macOS)NOTE: Under the hood, this uses make to run CMake, which then calls make again.
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. If you just run make, it will run CMake for you,
and put the result in bin/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.
gcc, clang, gcc-i686, emcc
debug, release
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
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
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/.
Some examples:
# parse and typecheck test.wat
$ 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.
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.
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
See wast2json.md.
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.
See wasm2c.md
See test/README.md.
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 Undefine 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
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.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。