wazero
packagemoduleThis package is not in the latest version of its module.
Details
Validgo.mod file
The Go module system was introduced in Go 1.11 and is the official dependency management solution for Go.
Redistributable license
Redistributable licenses place minimal restrictions on how software can be used, modified, and redistributed.
Tagged version
Modules with tagged versions give importers more predictable builds.
Stable version
When a project reaches major version v1 it is considered stable.
- Learn more about best practices
Repository
Links
README¶
wazero: the zero dependency WebAssembly runtime for Go developers
WebAssembly is a way to safely run code compiled in other languages. Runtimesexecute WebAssembly Modules (Wasm), which are most often binaries with a.wasmextension.
wazero is a WebAssembly Core Specification1.0 and2.0 compliantruntime written in Go. It haszero dependencies, and doesn't rely on CGO.This means you can run applications in other languages and still keep crosscompilation.
Import wazero and extend your Go application with code written in any language!
Example
The best way to learn wazero is by trying one of ourexamples. Themostbasic example extends a Go application with an additionfunction defined in WebAssembly.
Runtime
There are two runtime configurations supported in wazero:Compiler is default:
By default, exwazero.NewRuntime(ctx), the Compiler is used if supported. Youcan also force the interpreter like so:
r := wazero.NewRuntimeWithConfig(ctx, wazero.NewRuntimeConfigInterpreter())Interpreter
Interpreter is a naive interpreter-based implementation of Wasm virtualmachine. Its implementation doesn't have any platform (GOARCH, GOOS) specificcode, thereforeinterpreter can be used for any compilation target availablefor Go (such asriscv64).
Compiler
Compiler compiles WebAssembly modules into machine code ahead of time (AOT),duringRuntime.CompileModule. This means your WebAssembly functions executenatively at runtime. Compiler is faster than Interpreter, often by order ofmagnitude (10x) or more. This is done without host-specific dependencies.
Conformance
Both runtimes pass WebAssembly Core1.0 and2.0 specification testson supported platforms:
| Runtime | Usage | amd64 | arm64 | others |
|---|---|---|---|---|
| Interpreter | wazero.NewRuntimeConfigInterpreter() | ✅ | ✅ | ✅ |
| Compiler | wazero.NewRuntimeConfigCompiler() | ✅ | ✅ | ❌ |
Support Policy
The below support policy focuses on compatibility concerns of those embeddingwazero into their Go applications.
wazero
wazero's1.0 release happened in March 2023, and isin use by manyprojects and production sites.
We offer an API stability promise with semantic versioning. In other words, wepromise to not break any exported function signature without incrementing themajor version. This does not mean no innovation: New features and behaviorshappen with a minor version increment, e.g. 1.0.11 to 1.2.0. We also fix bugsor change internal details with a patch version, e.g. 1.0.0 to 1.0.1.
You can get the latest version of wazero like this.
go get github.com/tetratelabs/wazero@latestPlease give us astar if you end up using wazero!
Go
wazero has no dependencies except Go, so the only source of conflict in yourproject's use of wazero is the Go version.
wazero follows the same version policy as Go'sRelease Policy: twoversions. wazero will ensure these versions work and bugs are valid if there'san issue with a current Go version.
Additionally, wazero intentionally delays usage of language or standard libraryfeatures one additional version. For example, when Go 1.29 is released, wazerocan use language features or standard libraries added in 1.27. This is aconvenience for embedders who have a slower version policy than Go. However,only supported Go versions may be used to raise support issues.
Platform
wazero has two runtime modes: Interpreter and Compiler. The only supported operatingsystems are ones we test, but that doesn't necessarily mean other operatingsystem versions won't work.
We currently test Linux (Ubuntu and scratch), MacOS and Windows as packaged byGitHub Actions, as well as nested VMs running on Linux for FreeBSD, NetBSD,OpenBSD, DragonFly BSD, illumos and Solaris.
We also test cross compilation for manyGOOS andGOARCH combinations.
- Interpreter
- Linux is tested on amd64 and arm64 (native) as well as riscv64 via emulation.
- Windows, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, illumos and Solaris aretested only on amd64.
- macOS is tested only on arm64.
- Compiler
- Linux is tested on amd64 and arm64.
- Windows, FreeBSD, NetBSD, DragonFly BSD, illumos and Solaris aretested only on amd64.
- macOS is tested only on arm64.
wazero has no dependencies and doesn't require CGO. This means it can also beembedded in an application that doesn't use an operating system. This is a maindifferentiator between wazero and alternatives.
We verify zero dependencies by running tests in Docker'sscratch image.This approach ensures compatibility with any parent image.
macOS code-signing entitlements
If you're developing for macOS and need to code-sign your application,please read issue#2393.
wazero is a registered trademark of Tetrate.io, Inc. in the United States and/or other countries
Documentation¶
Overview¶
Example¶
This is an example of how to extend a Go application with an additionfunction defined in WebAssembly.
Since addWasm was compiled with TinyGo's `wasi` target, we need to configureWASI host imports.
A complete project that does the same as this is available here:https://github.com/tetratelabs/wazero/tree/main/examples/basic
package mainimport ("context"_ "embed""fmt""log""github.com/tetratelabs/wazero""github.com/tetratelabs/wazero/imports/wasi_snapshot_preview1")// addWasm was generated by the following:////cd examples/basic/testdata; tinygo build -o add.wasm -target=wasi add.go////go:embed examples/basic/testdata/add.wasmvar addWasm []byte// This is an example of how to extend a Go application with an addition// function defined in WebAssembly.//// Since addWasm was compiled with TinyGo's `wasi` target, we need to configure// WASI host imports.//// A complete project that does the same as this is available here:// https://github.com/tetratelabs/wazero/tree/main/examples/basicfunc main() {// Choose the context to use for function calls.ctx := context.Background()// Create a new WebAssembly Runtime.r := wazero.NewRuntime(ctx)defer r.Close(ctx) // This closes everything this Runtime created.// Instantiate WASI, which implements host functions needed for TinyGo to// implement `panic`.wasi_snapshot_preview1.MustInstantiate(ctx, r)// Instantiate the guest Wasm into the same runtime. It exports the `add`// function, implemented in WebAssembly.mod, err := r.InstantiateWithConfig(ctx, addWasm, wazero.NewModuleConfig().WithStartFunctions("_initialize"))if err != nil {log.Panicln(err)}// Call the `add` function and print the results to the console.x, y := uint64(1), uint64(2)results, err := mod.ExportedFunction("add").Call(ctx, x, y)if err != nil {log.Panicln(err)}fmt.Printf("%d + %d = %d\n", x, y, results[0])}Output:1 + 2 = 3
Example (CompileCache)¶
This is a basic example of using the file system compilation cache via wazero.NewCompilationCacheWithDir.The main goal is to show how it is configured.
package mainimport ("context"_ "embed""log""os""github.com/tetratelabs/wazero")// This is a basic example of using the file system compilation cache via wazero.NewCompilationCacheWithDir.// The main goal is to show how it is configured.func main() {// Prepare a cache directory.cacheDir, err := os.MkdirTemp("", "example")if err != nil {log.Panicln(err)}defer os.RemoveAll(cacheDir)ctx := context.Background()// Create a runtime config which shares a compilation cache directory.cache := newCompilationCacheWithDir(cacheDir)defer cache.Close(ctx)config := wazero.NewRuntimeConfig().WithCompilationCache(cache)// Using the same wazero.CompilationCache instance allows the in-memory cache sharing.newRuntimeCompileClose(ctx, config)newRuntimeCompileClose(ctx, config)// Since the above stored compiled functions to disk as well, below won't compile from scratch.// Instead, compilation result stored in the directory is re-used.newRuntimeCompileClose(ctx, config.WithCompilationCache(newCompilationCacheWithDir(cacheDir)))newRuntimeCompileClose(ctx, config.WithCompilationCache(newCompilationCacheWithDir(cacheDir)))}func newCompilationCacheWithDir(cacheDir string) wazero.CompilationCache {cache, err := wazero.NewCompilationCacheWithDir(cacheDir)if err != nil {log.Panicln(err)}return cache}// newRuntimeCompileClose creates a new wazero.Runtime, compile a binary, and then delete the runtime.func newRuntimeCompileClose(ctx context.Context, config wazero.RuntimeConfig) {r := wazero.NewRuntimeWithConfig(ctx, config)defer r.Close(ctx) // This closes everything this Runtime created except the file system cache._, err := r.CompileModule(ctx, addWasm)if err != nil {log.Panicln(err)}}Example (FsConfig)¶
This example shows how to configure an embed.FS.
package mainimport ("embed""io/fs""log""github.com/tetratelabs/wazero")//go:embed testdata/index.htmlvar testdataIndex embed.FSvar moduleConfig wazero.ModuleConfig// This example shows how to configure an embed.FS.func main() {// Strip the embedded path testdata/rooted, err := fs.Sub(testdataIndex, "testdata")if err != nil {log.Panicln(err)}moduleConfig = wazero.NewModuleConfig().// Make "index.html" accessible to the guest as "/index.html".WithFSConfig(wazero.NewFSConfig().WithFSMount(rooted, "/"))}Example (RuntimeConfig_WithCustomSections)¶
This is a basic example of retrieving custom sections using RuntimeConfig.WithCustomSections.
package mainimport ("context"_ "embed""log""github.com/tetratelabs/wazero""github.com/tetratelabs/wazero/api")// This is a basic example of retrieving custom sections using RuntimeConfig.WithCustomSections.func main() {ctx := context.Background()config := wazero.NewRuntimeConfig().WithCustomSections(true)r := wazero.NewRuntimeWithConfig(ctx, config)defer r.Close(ctx)m, err := r.CompileModule(ctx, addWasm)if err != nil {log.Panicln(err)}if m.CustomSections() == nil {log.Panicln("Custom sections should not be nil")}mustContain(m.CustomSections(), "producers")mustContain(m.CustomSections(), "target_features")}func mustContain(ss []api.CustomSection, name string) {for _, s := range ss {if s.Name() == name {return}}log.Panicf("Could not find section named %s\n", name)}Index¶
Examples¶
Constants¶
This section is empty.
Variables¶
This section is empty.
Functions¶
This section is empty.
Types¶
typeCompilationCache¶
CompilationCache reduces time spent compiling (Runtime.CompileModule) the same wasm module.
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- Instances of this can be reused across multiple runtimes, if configuredvia RuntimeConfig.
- The cache check happens before the compilation, so if multiple Goroutines aretrying to compile the same module simultaneously, it is possible that theyall compile the module. The design here is that the lock isn't held for the action "Compile"but only for checking and saving the compiled result. Therefore, we strongly recommend that the embedderdoes the centralized compilation in a single Goroutines (or multiple Goroutines per Wasm binary) to generate cache rather thantrying to Compile in parallel for a single module. In other words, we always recommend to produce CompiledModuleshare it across multiple Goroutines to avoid trying to compile the same module simultaneously.
funcNewCompilationCache¶
func NewCompilationCache()CompilationCache
NewCompilationCache returns a new CompilationCache to be passed to RuntimeConfig.This configures only in-memory cache, and doesn't persist to the file system. See wazero.NewCompilationCacheWithDir for detail.
The returned CompilationCache can be used to share the in-memory compilation results across multiple instances of wazero.Runtime.
funcNewCompilationCacheWithDir¶
func NewCompilationCacheWithDir(dirnamestring) (CompilationCache,error)
NewCompilationCacheWithDir is like wazero.NewCompilationCache except the result also writesstate into the directory specified by `dirname` parameter.
If the dirname doesn't exist, this creates it or returns an error.
Those running wazero as a CLI or frequently restarting a process using the same wasm shoulduse this feature to reduce time waiting to compile the same module a second time.
The contents written into dirname are wazero-version specific, meaning different versions ofwazero will duplicate entries for the same input wasm.
Note: The embedder must safeguard this directory from external changes.
typeCompiledModule¶
type CompiledModule interface {// Name returns the module name encoded into the binary or empty if not.Name()string// ImportedFunctions returns all the imported functions// (api.FunctionDefinition) in this module or nil if there are none.//// Note: Unlike ExportedFunctions, there is no unique constraint on// imports.ImportedFunctions() []api.FunctionDefinition// ExportedFunctions returns all the exported functions// (api.FunctionDefinition) in this module keyed on export name.ExportedFunctions() map[string]api.FunctionDefinition// ImportedMemories returns all the imported memories// (api.MemoryDefinition) in this module or nil if there are none.//// ## Notes// - As of WebAssembly Core Specification 2.0, there can be at most one// memory.// - Unlike ExportedMemories, there is no unique constraint on imports.ImportedMemories() []api.MemoryDefinition// ExportedMemories returns all the exported memories// (api.MemoryDefinition) in this module keyed on export name.//// Note: As of WebAssembly Core Specification 2.0, there can be at most one// memory.ExportedMemories() map[string]api.MemoryDefinition// CustomSections returns all the custom sections// (api.CustomSection) in this module keyed on the section name.CustomSections() []api.CustomSection// Close releases all the allocated resources for this CompiledModule.//// Note: It is safe to call Close while having outstanding calls from an// api.Module instantiated from this.Close(context.Context)error}CompiledModule is a WebAssembly module ready to be instantiated (Runtime.InstantiateModule) as an api.Module.
In WebAssembly terminology, this is a decoded, validated, and possibly also compiled module. wazero avoids usingthe name "Module" for both before and after instantiation as the name conflation has caused confusion.Seehttps://www.w3.org/TR/2019/REC-wasm-core-1-20191205/#semantic-phases%E2%91%A0
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- Closing the wazero.Runtime closes any CompiledModule it compiled.
typeFSConfig¶
type FSConfig interface {// WithDirMount assigns a directory at `dir` to any paths beginning at// `guestPath`.//// For example, `dirPath` as / (or c:\ in Windows), makes the entire host// volume writeable to the path on the guest. The `guestPath` is always a// POSIX style path, slash (/) delimited, even if run on Windows.//// If the same `guestPath` was assigned before, this overrides its value,// retaining the original precedence. See the documentation of FSConfig for// more details on `guestPath`.//// # Isolation//// The guest will have full access to this directory including escaping it// via relative path lookups like "../../". Full access includes operations// such as creating or deleting files, limited to any host level access// controls.//// # os.DirFS//// This configuration optimizes for WASI compatibility which is sometimes// at odds with the behavior of os.DirFS. Hence, this will not behave// exactly the same as os.DirFS. See /RATIONALE.md for more.WithDirMount(dir, guestPathstring)FSConfig// WithReadOnlyDirMount assigns a directory at `dir` to any paths// beginning at `guestPath`.//// This is the same as WithDirMount except only read operations are// permitted. However, escaping the directory via relative path lookups// like "../../" is still allowed.WithReadOnlyDirMount(dir, guestPathstring)FSConfig// WithFSMount assigns a fs.FS file system for any paths beginning at// `guestPath`.//// If the same `guestPath` was assigned before, this overrides its value,// retaining the original precedence. See the documentation of FSConfig for// more details on `guestPath`.//// # Isolation//// fs.FS does not restrict the ability to overwrite returned files via// io.Writer. Moreover, os.DirFS documentation includes important notes// about isolation, which also applies to fs.Sub. As of Go 1.19, the// built-in file-systems are not jailed (chroot). See//https://github.com/golang/go/issues/42322//// # os.DirFS//// Due to limited control and functionality available in os.DirFS, we// advise using WithDirMount instead. There will be behavior differences// between os.DirFS and WithDirMount, as the latter biases towards what's// expected from WASI implementations.//// # Custom fs.FileInfo//// The underlying implementation supports data not usually in fs.FileInfo// when `info.Sys` returns *sys.Stat_t. For example, a custom fs.FS can use// this approach to generate or mask sys.Inode data. Such a filesystem// needs to decorate any functions that can return fs.FileInfo://// - `Stat` as defined on `fs.File` (always)// - `Readdir` as defined on `os.File` (if defined)//// See sys.NewStat_t for examples.WithFSMount(fsfs.FS, guestPathstring)FSConfig}FSConfig configures filesystem paths the embedding host allows the wasmguest to access. Unconfigured paths are not allowed, so functions like`path_open` result in unsupported errors (e.g. syscall.ENOSYS).
Guest Path¶
`guestPath` is the name of the path the guest should use a filesystem for, orempty for any files.
All `guestPath` paths are normalized, specifically removing any leading ortrailing slashes. This means "/", "./" or "." all coerce to empty "".
Multiple `guestPath` values can be configured, but the last longest matchwins. For example, if "tmp", then "" were added, a request to open"tmp/foo.txt" use the filesystem associated with "tmp" even though a widerpath, "" (all files), was added later.
A `guestPath` of "." coerces to the empty string "" because the currentdirectory is handled by the guest. In other words, the guest resolves itescurrent directory prior to requesting files.
More notes on `guestPath`
- Working directories are typically tracked in wasm, though possible somerelative paths are requested. For example, TinyGo may attempt to resolvea path "../.." in unit tests.
- Zig uses the first path name it sees as the initial working directory ofthe process.
Scope¶
Configuration here is module instance scoped. This means you can use thesame configuration for multiple calls to Runtime.InstantiateModule. Eachmodule will have a different file descriptor table. Any errors accessingresources allowed here are deferred to instantiation time of each module.
Any host resources present at the time of configuration, but deleted beforeRuntime.InstantiateModule will trap/panic when the guest wasm initializes orcalls functions like `fd_read`.
Windows¶
While wazero supports Windows as a platform, all known compilers use POSIXconventions at runtime. For example, even when running on Windows, pathsused by wasm are separated by forward slash (/), not backslash (\).
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- FSConfig is immutable. Each WithXXX function returns a new instanceincluding the corresponding change.
- RATIONALE.md includes design background and relationship to WebAssemblySystem Interfaces (WASI).
funcNewFSConfig¶
func NewFSConfig()FSConfig
NewFSConfig returns a FSConfig that can be used for configuring module instantiation.
typeHostFunctionBuilder¶
type HostFunctionBuilder interface {// WithGoFunction is an advanced feature for those who need higher// performance than WithFunc at the cost of more complexity.//// Here's an example addition function:////builder.WithGoFunction(api.GoFunc(func(ctx context.Context, stack []uint64) {//x, y := api.DecodeI32(stack[0]), api.DecodeI32(stack[1])//sum := x + y//stack[0] = api.EncodeI32(sum)//}), []api.ValueType{api.ValueTypeI32, api.ValueTypeI32}, []api.ValueType{api.ValueTypeI32})//// As you can see above, defining in this way implies knowledge of which// WebAssembly api.ValueType is appropriate for each parameter and result.//// See WithGoModuleFunction if you also need to access the calling module.WithGoFunction(fnapi.GoFunction, params, results []api.ValueType)HostFunctionBuilder// WithGoModuleFunction is an advanced feature for those who need higher// performance than WithFunc at the cost of more complexity.//// Here's an example addition function that loads operands from memory:////builder.WithGoModuleFunction(api.GoModuleFunc(func(ctx context.Context, m api.Module, stack []uint64) {//mem := m.Memory()//offset := api.DecodeU32(stack[0])////x, _ := mem.ReadUint32Le(ctx, offset)//y, _ := mem.ReadUint32Le(ctx, offset + 4) // 32 bits == 4 bytes!//sum := x + y////stack[0] = api.EncodeU32(sum)//}), []api.ValueType{api.ValueTypeI32}, []api.ValueType{api.ValueTypeI32})//// As you can see above, defining in this way implies knowledge of which// WebAssembly api.ValueType is appropriate for each parameter and result.//// See WithGoFunction if you don't need access to the calling module.WithGoModuleFunction(fnapi.GoModuleFunction, params, results []api.ValueType)HostFunctionBuilder// WithFunc uses reflect.Value to map a go `func` to a WebAssembly// compatible Signature. An input that isn't a `func` will fail to// instantiate.//// Here's an example of an addition function:////builder.WithFunc(func(cxt context.Context, x, y uint32) uint32 {//return x + y//})//// # Defining a function//// Except for the context.Context and optional api.Module, all parameters// or result types must map to WebAssembly numeric value types. This means// uint32, int32, uint64, int64, float32 or float64.//// api.Module may be specified as the second parameter, usually to access// memory. This is important because there are only numeric types in Wasm.// The only way to share other data is via writing memory and sharing// offsets.////builder.WithFunc(func(ctx context.Context, m api.Module, offset uint32) uint32 {//mem := m.Memory()//x, _ := mem.ReadUint32Le(ctx, offset)//y, _ := mem.ReadUint32Le(ctx, offset + 4) // 32 bits == 4 bytes!//return x + y//})//// This example propagates context properly when calling other functions// exported in the api.Module:////builder.WithFunc(func(ctx context.Context, m api.Module, offset, byteCount uint32) uint32 {//fn = m.ExportedFunction("__read")//results, err := fn(ctx, offset, byteCount)//--snip--WithFunc(interface{})HostFunctionBuilder// WithName defines the optional module-local name of this function, e.g.// "random_get"//// Note: This is not required to match the Export name.WithName(namestring)HostFunctionBuilder// WithParameterNames defines optional parameter names of the function// signature, e.x. "buf", "buf_len"//// Note: When defined, names must be provided for all parameters.WithParameterNames(names ...string)HostFunctionBuilder// WithResultNames defines optional result names of the function// signature, e.x. "errno"//// Note: When defined, names must be provided for all results.WithResultNames(names ...string)HostFunctionBuilder// Export exports this to the HostModuleBuilder as the given name, e.g.// "random_get"Export(namestring)HostModuleBuilder}HostFunctionBuilder defines a host function (in Go), so that aWebAssembly binary (e.g. %.wasm file) can import and use it.
Here's an example of an addition function:
hostModuleBuilder.NewFunctionBuilder().WithFunc(func(cxt context.Context, x, y uint32) uint32 {return x + y}).Export("add")Memory¶
All host functions act on the importing api.Module, including any memoryexported in its binary (%.wasm file). If you are reading or writing memory,it is sand-boxed Wasm memory defined by the guest.
Below, `m` is the importing module, defined in Wasm. `fn` is a host functionadded via Export. This means that `x` was read from memory defined in Wasm,not arbitrary memory in the process.
fn := func(ctx context.Context, m api.Module, offset uint32) uint32 {x, _ := m.Memory().ReadUint32Le(ctx, offset)return x}Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
typeHostModuleBuilder¶
type HostModuleBuilder interface {// NewFunctionBuilder begins the definition of a host function.NewFunctionBuilder()HostFunctionBuilder// Compile returns a CompiledModule that can be instantiated by Runtime.Compile(context.Context) (CompiledModule,error)// Instantiate is a convenience that calls Compile, then Runtime.InstantiateModule.// This can fail for reasons documented on Runtime.InstantiateModule.//// Here's an example:////ctx := context.Background()//r := wazero.NewRuntime(ctx)//defer r.Close(ctx) // This closes everything this Runtime created.////hello := func() {//println("hello!")//}//env, _ := r.NewHostModuleBuilder("env").//NewFunctionBuilder().WithFunc(hello).Export("hello").//Instantiate(ctx)//// # Notes//// - Closing the Runtime has the same effect as closing the result.// - Fields in the builder are copied during instantiation: Later changes do not affect the instantiated result.// - To avoid using configuration defaults, use Compile instead.Instantiate(context.Context) (api.Module,error)}HostModuleBuilder is a way to define host functions (in Go), so that aWebAssembly binary (e.g. %.wasm file) can import and use them.
Specifically, this implements the host side of an Application BinaryInterface (ABI) like WASI or AssemblyScript.
For example, this defines and instantiates a module named "env" with onefunction:
ctx := context.Background()r := wazero.NewRuntime(ctx)defer r.Close(ctx) // This closes everything this Runtime created.hello := func() {println("hello!")}env, _ := r.NewHostModuleBuilder("env").NewFunctionBuilder().WithFunc(hello).Export("hello").Instantiate(ctx)If the same module may be instantiated multiple times, it is more efficientto separate steps. Here's an example:
compiled, _ := r.NewHostModuleBuilder("env").NewFunctionBuilder().WithFunc(getRandomString).Export("get_random_string").Compile(ctx)env1, _ := r.InstantiateModule(ctx, compiled, wazero.NewModuleConfig().WithName("env.1"))env2, _ := r.InstantiateModule(ctx, compiled, wazero.NewModuleConfig().WithName("env.2"))See HostFunctionBuilder for valid host function signatures and other details.
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- HostModuleBuilder is mutable: each method returns the same instance forchaining.
- methods do not return errors, to allow chaining. Any validation errorsare deferred until Compile.
- Functions are indexed in order of calls to NewFunctionBuilder asinsertion ordering is needed by ABI such as Emscripten (invoke_*).
- The semantics of host functions assumes the existence of an "importing module" because, for example, the host function needs access tothe memory of the importing module. Therefore, direct use of ExportedFunction is forbidden for host modules.Practically speaking, it is usually meaningless to directly call a host function from Go code as it is already somewhere in Go code.
typeModuleConfig¶
type ModuleConfig interface {// WithArgs assigns command-line arguments visible to an imported function that reads an arg vector (argv). Defaults to// none. Runtime.InstantiateModule errs if any arg is empty.//// These values are commonly read by the functions like "args_get" in "wasi_snapshot_preview1" although they could be// read by functions imported from other modules.//// Similar to os.Args and exec.Cmd Env, many implementations would expect a program name to be argv[0]. However, neither// WebAssembly nor WebAssembly System Interfaces (WASI) define this. Regardless, you may choose to set the first// argument to the same value set via WithName.//// Note: This does not default to os.Args as that violates sandboxing.//// Seehttps://linux.die.net/man/3/argv andhttps://en.wikipedia.org/wiki/Null-terminated_stringWithArgs(...string)ModuleConfig// WithEnv sets an environment variable visible to a Module that imports functions. Defaults to none.// Runtime.InstantiateModule errs if the key is empty or contains a NULL(0) or equals("") character.//// Validation is the same as os.Setenv on Linux and replaces any existing value. Unlike exec.Cmd Env, this does not// default to the current process environment as that would violate sandboxing. This also does not preserve order.//// Environment variables are commonly read by the functions like "environ_get" in "wasi_snapshot_preview1" although// they could be read by functions imported from other modules.//// While similar to process configuration, there are no assumptions that can be made about anything OS-specific. For// example, neither WebAssembly nor WebAssembly System Interfaces (WASI) define concerns processes have, such as// case-sensitivity on environment keys. For portability, define entries with case-insensitively unique keys.//// Seehttps://linux.die.net/man/3/environ andhttps://en.wikipedia.org/wiki/Null-terminated_stringWithEnv(key, valuestring)ModuleConfig// WithFS is a convenience that calls WithFSConfig with an FSConfig of the// input for the root ("/") guest path.WithFS(fs.FS)ModuleConfig// WithFSConfig configures the filesystem available to each guest// instantiated with this configuration. By default, no file access is// allowed, so functions like `path_open` result in unsupported errors// (e.g. syscall.ENOSYS).WithFSConfig(FSConfig)ModuleConfig// WithName configures the module name. Defaults to what was decoded from// the name section. Duplicate names are not allowed in a single Runtime.//// Calling this with the empty string "" makes the module anonymous.// That is useful when you want to instantiate the same CompiledModule multiple times like below://// for i := 0; i < N; i++ {//// Instantiate a new Wasm module from the already compiled `compiledWasm` anonymously without a name.//instance, err := r.InstantiateModule(ctx, compiledWasm, wazero.NewModuleConfig().WithName(""))//// ....//}//// See the `concurrent-instantiation` example for a complete usage.//// Non-empty named modules are available for other modules to import by name.WithName(string)ModuleConfig// WithStartFunctions configures the functions to call after the module is// instantiated. Defaults to "_start".//// Clearing the default is supported, via `WithStartFunctions()`.//// # Notes//// - If a start function doesn't exist, it is skipped. However, any that// do exist are called in order.// - Start functions are not intended to be called multiple times.// Functions that should be called multiple times should be invoked// manually via api.Module's `ExportedFunction` method.// - Start functions commonly exit the module during instantiation,// preventing use of any functions later. This is the case in "wasip1",// which defines the default value "_start".// - See /RATIONALE.md for motivation of this feature.WithStartFunctions(...string)ModuleConfig// WithStderr configures where standard error (file descriptor 2) is written. Defaults to io.Discard.//// This writer is most commonly used by the functions like "fd_write" in "wasi_snapshot_preview1" although it could// be used by functions imported from other modules.//// # Notes//// - The caller is responsible to close any io.Writer they supply: It is not closed on api.Module Close.// - This does not default to os.Stderr as that both violates sandboxing and prevents concurrent modules.//// Seehttps://linux.die.net/man/3/stderrWithStderr(io.Writer)ModuleConfig// WithStdin configures where standard input (file descriptor 0) is read. Defaults to return io.EOF.//// This reader is most commonly used by the functions like "fd_read" in "wasi_snapshot_preview1" although it could// be used by functions imported from other modules.//// # Notes//// - The caller is responsible to close any io.Reader they supply: It is not closed on api.Module Close.// - This does not default to os.Stdin as that both violates sandboxing and prevents concurrent modules.//// Seehttps://linux.die.net/man/3/stdinWithStdin(io.Reader)ModuleConfig// WithStdout configures where standard output (file descriptor 1) is written. Defaults to io.Discard.//// This writer is most commonly used by the functions like "fd_write" in "wasi_snapshot_preview1" although it could// be used by functions imported from other modules.//// # Notes//// - The caller is responsible to close any io.Writer they supply: It is not closed on api.Module Close.// - This does not default to os.Stdout as that both violates sandboxing and prevents concurrent modules.//// Seehttps://linux.die.net/man/3/stdoutWithStdout(io.Writer)ModuleConfig// WithWalltime configures the wall clock, sometimes referred to as the// real time clock. sys.Walltime returns the current unix/epoch time,// seconds since midnight UTC 1 January 1970, with a nanosecond fraction.// This defaults to a fake result that increases by 1ms on each reading.//// Here's an example that uses a custom clock://moduleConfig = moduleConfig.//WithWalltime(func(context.Context) (sec int64, nsec int32) {//return clock.walltime()//}, sys.ClockResolution(time.Microsecond.Nanoseconds()))//// # Notes:// - This does not default to time.Now as that violates sandboxing.// - This is used to implement host functions such as WASI// `clock_time_get` with the `realtime` clock ID.// - Use WithSysWalltime for a usable implementation.WithWalltime(sys.Walltime,sys.ClockResolution)ModuleConfig// WithSysWalltime uses time.Now for sys.Walltime with a resolution of 1us// (1000ns).//// See WithWalltimeWithSysWalltime()ModuleConfig// WithNanotime configures the monotonic clock, used to measure elapsed// time in nanoseconds. Defaults to a fake result that increases by 1ms// on each reading.//// Here's an example that uses a custom clock://moduleConfig = moduleConfig.//WithNanotime(func(context.Context) int64 {//return clock.nanotime()//}, sys.ClockResolution(time.Microsecond.Nanoseconds()))//// # Notes:// - This does not default to time.Since as that violates sandboxing.// - This is used to implement host functions such as WASI// `clock_time_get` with the `monotonic` clock ID.// - Some compilers implement sleep by looping on sys.Nanotime (e.g. Go).// - If you set this, you should probably set WithNanosleep also.// - Use WithSysNanotime for a usable implementation.WithNanotime(sys.Nanotime,sys.ClockResolution)ModuleConfig// WithSysNanotime uses time.Now for sys.Nanotime with a resolution of 1us.//// See WithNanotimeWithSysNanotime()ModuleConfig// WithNanosleep configures the how to pause the current goroutine for at// least the configured nanoseconds. Defaults to return immediately.//// This example uses a custom sleep function://moduleConfig = moduleConfig.//WithNanosleep(func(ns int64) {//rel := unix.NsecToTimespec(ns)//remain := unix.Timespec{}//for { // loop until no more time remaining//err := unix.ClockNanosleep(unix.CLOCK_MONOTONIC, 0, &rel, &remain)//--snip--//// # Notes:// - This does not default to time.Sleep as that violates sandboxing.// - This is used to implement host functions such as WASI `poll_oneoff`.// - Some compilers implement sleep by looping on sys.Nanotime (e.g. Go).// - If you set this, you should probably set WithNanotime also.// - Use WithSysNanosleep for a usable implementation.WithNanosleep(sys.Nanosleep)ModuleConfig// WithOsyield yields the processor, typically to implement spin-wait// loops. Defaults to return immediately.//// # Notes:// - This primarily supports `sched_yield` in WASI// - This does not default to runtime.osyield as that violates sandboxing.WithOsyield(sys.Osyield)ModuleConfig// WithSysNanosleep uses time.Sleep for sys.Nanosleep.//// See WithNanosleepWithSysNanosleep()ModuleConfig// WithRandSource configures a source of random bytes. Defaults to return a// deterministic source. You might override this with crypto/rand.Reader//// This reader is most commonly used by the functions like "random_get" in// "wasi_snapshot_preview1", "seed" in AssemblyScript standard "env", and// "getRandomData" when runtime.GOOS is "js".//// Note: The caller is responsible to close any io.Reader they supply: It// is not closed on api.Module Close.WithRandSource(io.Reader)ModuleConfig}ModuleConfig configures resources needed by functions that have low-level interactions with the host operatingsystem. Using this, resources such as STDIN can be isolated, so that the same module can be safely instantiatedmultiple times.
Here's an example:
// Initialize base configuration:config := wazero.NewModuleConfig().WithStdout(buf).WithSysNanotime()// Assign different configuration on each instantiationmod, _ := r.InstantiateModule(ctx, compiled, config.WithName("rotate").WithArgs("rotate", "angle=90", "dir=cw"))While wazero supports Windows as a platform, host functions using ModuleConfig follow a UNIX dialect.See RATIONALE.md for design background and relationship to WebAssembly System Interfaces (WASI).
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- ModuleConfig is immutable. Each WithXXX function returns a new instanceincluding the corresponding change.
funcNewModuleConfig¶
func NewModuleConfig()ModuleConfig
NewModuleConfig returns a ModuleConfig that can be used for configuring module instantiation.
typeRuntime¶
type Runtime interface {// Instantiate instantiates a module from the WebAssembly binary (%.wasm)// with default configuration, which notably calls the "_start" function,// if it exists.//// Here's an example://ctx := context.Background()//r := wazero.NewRuntime(ctx)//defer r.Close(ctx) // This closes everything this Runtime created.////mod, _ := r.Instantiate(ctx, wasm)//// # Notes//// - See notes on InstantiateModule for error scenarios.// - See InstantiateWithConfig for configuration overrides.Instantiate(ctxcontext.Context, source []byte) (api.Module,error)// InstantiateWithConfig instantiates a module from the WebAssembly binary// (%.wasm) or errs for reasons including exit or validation.//// Here's an example://ctx := context.Background()//r := wazero.NewRuntime(ctx)//defer r.Close(ctx) // This closes everything this Runtime created.////mod, _ := r.InstantiateWithConfig(ctx, wasm,//wazero.NewModuleConfig().WithName("rotate"))//// # Notes//// - See notes on InstantiateModule for error scenarios.// - If you aren't overriding defaults, use Instantiate.// - This is a convenience utility that chains CompileModule with// InstantiateModule. To instantiate the same source multiple times,// use CompileModule as InstantiateModule avoids redundant decoding// and/or compilation.InstantiateWithConfig(ctxcontext.Context, source []byte, configModuleConfig) (api.Module,error)// NewHostModuleBuilder lets you create modules out of functions defined in Go.//// Below defines and instantiates a module named "env" with one function:////ctx := context.Background()//hello := func() {//fmt.Fprintln(stdout, "hello!")//}//_, err := r.NewHostModuleBuilder("env").//NewFunctionBuilder().WithFunc(hello).Export("hello").//Instantiate(ctx, r)//// Note: empty `moduleName` is not allowed.NewHostModuleBuilder(moduleNamestring)HostModuleBuilder// CompileModule decodes the WebAssembly binary (%.wasm) or errs if invalid.// Any pre-compilation done after decoding wasm is dependent on RuntimeConfig.//// There are two main reasons to use CompileModule instead of Instantiate:// - Improve performance when the same module is instantiated multiple times under different names// - Reduce the amount of errors that can occur during InstantiateModule.//// # Notes//// - The resulting module name defaults to what was binary from the custom name section.// - Any pre-compilation done after decoding the source is dependent on RuntimeConfig.//// Seehttps://www.w3.org/TR/2019/REC-wasm-core-1-20191205/#name-section%E2%91%A0CompileModule(ctxcontext.Context, binary []byte) (CompiledModule,error)// InstantiateModule instantiates the module or errs for reasons including// exit or validation.//// Here's an example://mod, _ := n.InstantiateModule(ctx, compiled, wazero.NewModuleConfig().//WithName("prod"))//// # Errors//// While CompiledModule is pre-validated, there are a few situations which// can cause an error:// - The module name is already in use.// - The module has a table element initializer that resolves to an index// outside the Table minimum size.// - The module has a start function, and it failed to execute.// - The module was compiled to WASI and exited with a non-zero exit// code, you'll receive a sys.ExitError.// - RuntimeConfig.WithCloseOnContextDone was enabled and a context// cancellation or deadline triggered before a start function returned.InstantiateModule(ctxcontext.Context, compiledCompiledModule, configModuleConfig) (api.Module,error)// CloseWithExitCode closes all the modules that have been initialized in this Runtime with the provided exit code.// An error is returned if any module returns an error when closed.//// Here's an example://ctx := context.Background()//r := wazero.NewRuntime(ctx)//defer r.CloseWithExitCode(ctx, 2) // This closes everything this Runtime created.////// Everything below here can be closed, but will anyway due to above.//_, _ = wasi_snapshot_preview1.InstantiateSnapshotPreview1(ctx, r)//mod, _ := r.Instantiate(ctx, wasm)CloseWithExitCode(ctxcontext.Context, exitCodeuint32)error// Module returns an instantiated module in this runtime or nil if there aren't any.Module(moduleNamestring)api.Module// Closer closes all compiled code by delegating to CloseWithExitCode with an exit code of zero.api.Closer}Runtime allows embedding of WebAssembly modules.
The below is an example of basic initialization:
ctx := context.Background()r := wazero.NewRuntime(ctx)defer r.Close(ctx) // This closes everything this Runtime created.mod, _ := r.Instantiate(ctx, wasm)
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- Closing this closes any CompiledModule or Module it instantiated.
funcNewRuntime¶
NewRuntime returns a runtime with a configuration assigned by NewRuntimeConfig.
funcNewRuntimeWithConfig¶
func NewRuntimeWithConfig(ctxcontext.Context, rConfigRuntimeConfig)Runtime
NewRuntimeWithConfig returns a runtime with the given configuration.
typeRuntimeConfig¶
type RuntimeConfig interface {// WithCoreFeatures sets the WebAssembly Core specification features this// runtime supports. Defaults to api.CoreFeaturesV2.//// Example of disabling a specific feature://features := api.CoreFeaturesV2.SetEnabled(api.CoreFeatureMutableGlobal, false)//rConfig = wazero.NewRuntimeConfig().WithCoreFeatures(features)//// # Why default to version 2.0?//// Many compilers that target WebAssembly require features after// api.CoreFeaturesV1 by default. For example, TinyGo v0.24+ requires// api.CoreFeatureBulkMemoryOperations. To avoid runtime errors, wazero// defaults to api.CoreFeaturesV2, even though it is not yet a Web// Standard (REC).WithCoreFeatures(api.CoreFeatures)RuntimeConfig// WithMemoryLimitPages overrides the maximum pages allowed per memory. The// default is 65536, allowing 4GB total memory per instance if the maximum is// not encoded in a Wasm binary. Setting a value larger than default will panic.//// This example reduces the largest possible memory size from 4GB to 128KB://rConfig = wazero.NewRuntimeConfig().WithMemoryLimitPages(2)//// Note: Wasm has 32-bit memory and each page is 65536 (2^16) bytes. This// implies a max of 65536 (2^16) addressable pages.// Seehttps://www.w3.org/TR/2019/REC-wasm-core-1-20191205/#grow-memWithMemoryLimitPages(memoryLimitPagesuint32)RuntimeConfig// WithMemoryCapacityFromMax eagerly allocates max memory, unless max is// not defined. The default is false, which means minimum memory is// allocated and any call to grow memory results in re-allocations.//// This example ensures any memory.grow instruction will never re-allocate://rConfig = wazero.NewRuntimeConfig().WithMemoryCapacityFromMax(true)//// Seehttps://www.w3.org/TR/2019/REC-wasm-core-1-20191205/#grow-mem//// Note: if the memory maximum is not encoded in a Wasm binary, this// results in allocating 4GB. See the doc on WithMemoryLimitPages for detail.WithMemoryCapacityFromMax(memoryCapacityFromMaxbool)RuntimeConfig// WithDebugInfoEnabled toggles DWARF based stack traces in the face of// runtime errors. Defaults to true.//// Those who wish to disable this, can like so:////r := wazero.NewRuntimeWithConfig(wazero.NewRuntimeConfig().WithDebugInfoEnabled(false)//// When disabled, a stack trace message looks like:////wasm stack trace://.runtime._panic(i32)//.myFunc()//.main.main()//.runtime.run()//._start()//// When enabled, the stack trace includes source code information:////wasm stack trace://.runtime._panic(i32)// 0x16e2: /opt/homebrew/Cellar/tinygo/0.26.0/src/runtime/runtime_tinygowasm.go:73:6//.myFunc()// 0x190b: /Users/XXXXX/wazero/internal/testing/dwarftestdata/testdata/main.go:19:7//.main.main()// 0x18ed: /Users/XXXXX/wazero/internal/testing/dwarftestdata/testdata/main.go:4:3//.runtime.run()// 0x18cc: /opt/homebrew/Cellar/tinygo/0.26.0/src/runtime/scheduler_none.go:26:10//._start()// 0x18b6: /opt/homebrew/Cellar/tinygo/0.26.0/src/runtime/runtime_wasm_wasi.go:22:5//// Note: This only takes into effect when the original Wasm binary has the// DWARF "custom sections" that are often stripped, depending on// optimization flags passed to the compiler.WithDebugInfoEnabled(bool)RuntimeConfig// WithCompilationCache configures how runtime caches the compiled modules. In the default configuration, compilation results are// only in-memory until Runtime.Close is closed, and not shareable by multiple Runtime.//// Below defines the shared cache across multiple instances of Runtime:////// Creates the new Cache and the runtime configuration with it.//cache := wazero.NewCompilationCache()//defer cache.Close()//config := wazero.NewRuntimeConfig().WithCompilationCache(c)////// Creates two runtimes while sharing compilation caches.//foo := wazero.NewRuntimeWithConfig(context.Background(), config)// bar := wazero.NewRuntimeWithConfig(context.Background(), config)//// # Cache Key//// Cached files are keyed on the version of wazero. This is obtained from go.mod of your application,// and we use it to verify the compatibility of caches against the currently-running wazero.// However, if you use this in tests of a package not named as `main`, then wazero cannot obtain the correct// version of wazero due to the known issue of debug.BuildInfo function:https://github.com/golang/go/issues/33976.// As a consequence, your cache won't contain the correct version information and always be treated as `dev` version.// To avoid this issue, you can pass -ldflags "-X github.com/tetratelabs/wazero/internal/version.version=foo" when running tests.WithCompilationCache(CompilationCache)RuntimeConfig// WithCustomSections toggles parsing of "custom sections". Defaults to false.//// When enabled, it is possible to retrieve custom sections from a CompiledModule:////config := wazero.NewRuntimeConfig().WithCustomSections(true)//r := wazero.NewRuntimeWithConfig(ctx, config)//c, err := r.CompileModule(ctx, wasm)//customSections := c.CustomSections()WithCustomSections(bool)RuntimeConfig// WithCloseOnContextDone ensures the executions of functions to be terminated under one of the following circumstances://// - context.Context passed to the Call method of api.Function is canceled during execution. (i.e. ctx by context.WithCancel)// - context.Context passed to the Call method of api.Function reaches timeout during execution. (i.e. ctx by context.WithTimeout or context.WithDeadline)// - Close or CloseWithExitCode of api.Module is explicitly called during execution.//// This is especially useful when one wants to run untrusted Wasm binaries since otherwise, any invocation of// api.Function can potentially block the corresponding Goroutine forever. Moreover, it might block the// entire underlying OS thread which runs the api.Function call. See "Why it's safe to execute runtime-generated// machine codes against async Goroutine preemption" section in RATIONALE.md for detail.//// Upon the termination of the function executions, api.Module is closed.//// Note that this comes with a bit of extra cost when enabled. The reason is that internally this forces// interpreter and compiler runtimes to insert the periodical checks on the conditions above. For that reason,// this is disabled by default.//// See examples in context_done_example_test.go for the end-to-end demonstrations.//// When the invocations of api.Function are closed due to this, sys.ExitError is raised to the callers and// the api.Module from which the functions are derived is made closed.WithCloseOnContextDone(bool)RuntimeConfig}RuntimeConfig controls runtime behavior, with the default implementation asNewRuntimeConfig
The example below explicitly limits to Wasm Core 1.0 features as opposed torelying on defaults:
rConfig = wazero.NewRuntimeConfig().WithCoreFeatures(api.CoreFeaturesV1)
Notes¶
- This is an interface for decoupling, not third-party implementations.All implementations are in wazero.
- RuntimeConfig is immutable. Each WithXXX function returns a new instanceincluding the corresponding change.
funcNewRuntimeConfig¶
func NewRuntimeConfig()RuntimeConfig
NewRuntimeConfig returns a RuntimeConfig using the compiler if it is supported in this environment,or the interpreter otherwise.
funcNewRuntimeConfigCompiler¶
func NewRuntimeConfigCompiler()RuntimeConfig
NewRuntimeConfigCompiler compiles WebAssembly modules intoruntime.GOARCH-specific assembly for optimal performance.
The default implementation is AOT (Ahead of Time) compilation, applied atRuntime.CompileModule. This allows consistent runtime performance, as wellthe ability to reduce any first request penalty.
Note: While this is technically AOT, this does not imply any action on yourpart. wazero automatically performs ahead-of-time compilation as needed whenRuntime.CompileModule is invoked.
Warning¶
This panics at runtime if the runtime.GOOS or runtime.GOARCH does notsupport compiler. Use NewRuntimeConfig to safely detect and fallback toNewRuntimeConfigInterpreter if needed.
If you are using wazero in buildmode=c-archive or c-shared, make sure that you set up the alternate signal stackby using, e.g. `sigaltstack` combined with `SA_ONSTACK` flag on `sigaction` on Linux,before calling any api.Function. This is because the Go runtime does not set up the alternate signal stackfor c-archive or c-shared modes, and wazero uses the different stack than the calling Goroutine.Hence, the signal handler might get invoked on the wazero's stack, which may cause a stack overflow.https://github.com/tetratelabs/wazero/blob/2092c0a879f30d49d7b37f333f4547574b8afe0d/internal/integration_test/fuzz/fuzz/tests/sigstack.rs#L19-L36
funcNewRuntimeConfigInterpreter¶
func NewRuntimeConfigInterpreter()RuntimeConfig
NewRuntimeConfigInterpreter interprets WebAssembly modules instead of compiling them into assembly.
Directories¶
| Path | Synopsis |
|---|---|
Package api includes constants and interfaces used by both end-users and internal implementations. | Package api includes constants and interfaces used by both end-users and internal implementations. |
cmd | |
wazerocommand | |
examples | |
allocation/rustcommand | |
allocation/tinygocommand | |
allocation/zigcommand | |
basiccommand | |
concurrent-instantiationcommand | |
import-gocommand | |
multiple-resultscommand | |
multiple-runtimescommand | |
Package experimental includes features we aren't yet sure about. | Package experimental includes features we aren't yet sure about. |
sysfs Package sysfs includes a low-level filesystem interface and utilities needed for WebAssembly host functions (ABI) such as WASI. | Package sysfs includes a low-level filesystem interface and utilities needed for WebAssembly host functions (ABI) such as WASI. |
imports | |
assemblyscript Package assemblyscript contains Go-defined special functions imported by AssemblyScript under the module name "env". | Package assemblyscript contains Go-defined special functions imported by AssemblyScript under the module name "env". |
assemblyscript/examplecommand | |
emscripten Package emscripten contains Go-defined special functions imported by Emscripten under the module name "env". | Package emscripten contains Go-defined special functions imported by Emscripten under the module name "env". |
wasi_snapshot_preview1 Package wasi_snapshot_preview1 contains Go-defined functions to access system calls, such as opening a file, similar to Go's x/sys package. | Package wasi_snapshot_preview1 contains Go-defined functions to access system calls, such as opening a file, similar to Go's x/sys package. |
internal | |
engine/wazevo/backend Package backend must be free of Wasm-specific concept. | Package backend must be free of Wasm-specific concept. |
engine/wazevo/backend/regalloc Package regalloc performs register allocation. | Package regalloc performs register allocation. |
engine/wazevo/frontend Package frontend implements the translation of WebAssembly to SSA IR using the ssa package. | Package frontend implements the translation of WebAssembly to SSA IR using the ssa package. |
engine/wazevo/ssa Package ssa is used to construct SSA function. | Package ssa is used to construct SSA function. |
expctxkeys Package expctxkeys provides keys for the context used to store the experimental APIs. | Package expctxkeys provides keys for the context used to store the experimental APIs. |
fstest Package fstest defines filesystem test cases that help validate host functions implementing WASI. | Package fstest defines filesystem test cases that help validate host functions implementing WASI. |
logging Package logging includes utilities used to log function calls. | Package logging includes utilities used to log function calls. |
platform Package platform includes runtime-specific code needed for the compiler or otherwise. | Package platform includes runtime-specific code needed for the compiler or otherwise. |
sysfs Package sysfs includes a low-level filesystem interface and utilities needed for WebAssembly host functions (ABI) such as WASI. | Package sysfs includes a low-level filesystem interface and utilities needed for WebAssembly host functions (ABI) such as WASI. |
testing/require Package require includes test assertions that fail the test immediately. | Package require includes test assertions that fail the test immediately. |
wasip1 Package wasip1 is a helper to remove package cycles re-using constants. | Package wasip1 is a helper to remove package cycles re-using constants. |
wasmdebug Package wasmdebug contains utilities used to give consistent search keys between stack traces and error messages. | Package wasmdebug contains utilities used to give consistent search keys between stack traces and error messages. |
wasmruntime Package wasmruntime contains internal symbols shared between modules for error handling. | Package wasmruntime contains internal symbols shared between modules for error handling. |
integration_testmodule | |
integration_test/asmmodule | |
integration_test/fuzzmodule | |
integration_test/vsmodule | |
Package sys includes constants and types used by both public and internal APIs. | Package sys includes constants and types used by both public and internal APIs. |