wasm3 / wasm3-rs Goto Github PK

Rust wrapper for Wasm3, the fastest WebAssembly interpreter

License: MIT License

Rust 99.10% Python 0.90%

wasm3-rs's Introduction

Note

I regret to inform the community that since my house was destroyed by russians who invaded my country, Wasm3 will enter a minimal maintenance phase. At this time, I am unable to continue the development of new features. However, I am committed to keeping the project alive and will actively review and merge incoming Pull Requests. I deeply appreciate your understanding and support during this difficult period. Your contributions to Wasm3 are now more valuable than ever.

Wasm3

A fast WebAssembly interpreter and the most universal WASM runtime.
_{Based on CoreMark 1.0 and independent benchmarks. Your mileage may vary.}

Getting Started

Here's a small getting started guide. Click here to start:

Installation

Please follow the installation instructions.

Wasm3 can also be used as a library for:

Python3 │ Rust │ C/C++ │ GoLang │ Zig │ Perl
Swift │ .Net │ Nim │ Arduino, PlatformIO, Particle │ QuickJS

Status

wasm3 passes the WebAssembly spec testsuite and is able to run many WASI apps.

Minimum useful system requirements: ~64Kb for code and ~10Kb RAM

wasm3 runs on a wide range of architectures (x86, x86_64, ARM, RISC-V, PowerPC, MIPS, Xtensa, ARC32, ...) and platforms:

Linux, Windows, OS X, FreeBSD, Android, iOS
OpenWrt, Yocto, Buildroot (routers, modems, etc.)
Raspberry Pi, Orange Pi and other SBCs
MCUs: Arduino, ESP8266, ESP32, Particle, ... see full list
Browsers. Yes, using WebAssembly itself!
wasm3 can execute wasm3 (self-hosting)

Features

Webassembly Core Proposals	Extra
☑ Import/Export of Mutable Globals	☑ Structured execution tracing
☑ Non-trapping float-to-int conversions	☑ Big-Endian systems support
☑ Sign-extension operators	☑ Wasm and WASI self-hosting
☑ Multi-value	☑ Gas metering
☑ Bulk memory operations (partial support)	☑ Linear memory limit (< 64KiB)
☐ Multiple memories
☐ Reference types
☐ Tail call optimization
☐ Fixed-width SIMD
☐ Exception handling

Motivation

Why use a "slow interpreter" versus a "fast JIT"?

In many situations, speed is not the main concern. Runtime executable size, memory usage, startup latency can be improved with the interpreter approach. Portability and security are much easier to achieve and maintain. Additionally, development impedance is much lower. A simple library like Wasm3 is easy to compile and integrate into an existing project. (Wasm3 builds in a just few seconds). Finally, on some platforms (i.e. iOS and WebAssembly itself) you can't generate executable code pages in runtime, so JIT is unavailable.

Why would you want to run WASM on embedded devices?

Wasm3 started as a research project and remains so by any means. Evaluating the engine in different environments is part of the research. Given that we have Lua, JS, Python, Lisp, ... running on MCUs, WebAssembly is a promising alternative. It provides toolchain decoupling as well as a completely sandboxed, well-defined, predictable environment. Among practical use cases we can list edge computing, scripting, plugin systems, running IoT rules, smart contracts, etc.

Used by

Further Resources

Demos
Installation instructions
Cookbook
Troubleshooting
Build and Development instructions
Supported Hardware
Testing & Fuzzing
Performance
Interpreter Architecture
Logging
Awesome WebAssembly Tools

License

This project is released under The MIT License (MIT)

wasm3-rs's People

Contributors

Stargazers

Watchers

wasm3-rs's Issues

expose a wasm3 runtime's `memoryLimit`

wasm3 allows one to limit the amount of memory available to the runtime through the following code:

https://github.com/wasm3/wasm3/blob/640bf0cc2671f1725234536c3cd4be50de6cc19e/source/m3_env.h#L246

Which can be modified either by changing memoryLimit directly or by calling ResizeMemory, which takes an IM3Runtime as well as the number of pages:

https://github.com/wasm3/wasm3/blob/bdc50827555399c51316273ef15b3358ca196e41/source/m3_env.c#L454

The ability to limit the maximum number of pages available to the runtime is important in environments where the device running wasm3 can only allocate a few pages of memory.

Would you accept a PR to allow resizing the runtime's allocated memory?

Upgrading to master from b1d3b4 (Feb 25) introduces error in make_func_wrapper!

I had this code in my repository, but since updating to master I am starting to get this error generated during compile time:

error[E0425]: cannot find value `SIZE_IN_SLOT_COUNT` in the crate root
   --> src/eval.rs:194:1
    |
194 | wasm3::make_func_wrapper!(wasm_extmem_store_8_wrap: wasm_extmem_store_8(address: u64, value: u64));
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in the crate root

Thanks!

How to call host functions in wasm3 rust api?

In the following wat file :
test.txt

It wants to call the function assert_eq_i32 and print_input from host, how to call the host functions in wasm3 by rust api ?

Example for string/vec u8 transfer

Is there an example that can show passing a String or a Vec both ways?

use-32bit-slots feature is broken

#[no_mangle]
pub extern "C" fn add_u32(foo: u32, bar: u32) -> u32 {
    foo + bar
}

This function returns the correct result when using 64bit slots, but an incorrect result when using 32bit slots.

Bindgen version used by wasm3-sys on crates.io doesn't match the source code

This repository's source code says it uses bindgen v0.59, but the version on crates.io uses bindgen v0.54.0.

I'm not quite sure how that happened when the commit bumping the bindgen version literally says "Released 0.2.0" and we're on 0.3.0 now, but would you be able to release a new version of wasm3-sys so the dependencies line up?

At the moment I'm having issues because another dependency uses the latest bindgen version (v0.59.1) and the two bindgen versions are causing a link conflict with clang-sys.

Module find_function is producing an opaque Wasm3Error

I've been having some trouble using the find_function function to find an export from a loaded module. Originally thought it was because of the new closure stuff, but in working on reducing the code down to a reproducible test, even removing all the linked closures and still calling find_function, it's still resulting in an error. The problem is, the error is somewhat opaque: Wasm3(Wasm3Error(0x7ff7549b9468)). It seems that either something is wrong with the wasm that I'm trying to load, and it would be useful to have the facility to get at the underlying error details or message, or something is happening in the library's find_function code, where fixing that issue will make the opaque error stuff moot.

Code to reproduce is here: https://gist.github.com/ericflo/92bc57abb301a2b66474913ee0c1d919 and the system.wasm is hosted here: https://www.siacdn.com/_BGbMn73JOQub3XQgqyRmoDJgBlZLfe7EHLTjaGblCX1mw - It's a custom quickjs build with a few extra import/exports that I'm trying to hook with these rust bindings.

Multi-Value Return Types

wasm3 seems to support multi-value, but Module::find_function only accepts WasmType return types.

Is this just a matter of updating the function signature and some glue, or is there some blocker due to the the wasm3 C api?

Closure with arguments

The ability to link a closure is super useful, but I'm running into trouble specifying the closure type signature when linking a closure with arguments. For example, I want to register a function which takes two i32s and returns nothing. The problem is that the link_closure closure signature requires Sized, but boxing the closure doesn't seem to work either. Attached below is an example of what I've been trying (this doesn't compile because it needs Sized). Any clarification on how these closure args should be specified would be much appreciated - thanks!

use std::sync::{Arc, Mutex};

use anyhow::{Result};
use wasm3::{Module, Runtime};

use super::interop;

type LogDebugClosureType = dyn FnMut(i32, i32) -> () + 'static;

pub fn link_closures(rt_mtx: Arc<Mutex<Runtime>>, module: &mut Module) -> Result<()> {
    module.link_closure::<(i32, i32), (), LogDebugClosureType>("env", "Engine_Log_Debug", make_log_debug(rt_mtx));
    Ok(())
}

fn make_log_debug(rt_mtx: Arc<Mutex<Runtime>>) -> impl FnMut(i32, i32) -> () + 'static {
    move |ptr: i32, len: i32| -> () {
        let line = match interop::read(rt_mtx.clone(), ptr, len) {
            Ok(s) => s,
            Err(err) => {
                error!("Got error reading string: {:?}", err);
                return ()
            },
        };
        info!("DEBUG: {}", line);
    }
}

`ParsedModule` API is unsound

According to https://github.com/wasm3/wasm3/blob/8850f91c46510ca44097e8b1d55441bc4de544e5/source/wasm3.h#L218-L222, the WASM bytecode passed to m3_ParseModule needs to stay alive during the module's lifetime, but the wasm3-rs API does not enforce this with a lifetime parameter. The following code causes a segmentation fault:

use std::fs;

use wasm3::{Environment, Function, ParsedModule, Runtime};

fn open() -> Result<Runtime, Box<dyn std::error::Error>> {
    let wasm = fs::read("empty.wasm")?;

    let env = Environment::new()?;
    let parsed_module = ParsedModule::parse(&env, &wasm)?;

    let rt = Runtime::new(&env, 1024 * 16)?;
    rt.load_module(parsed_module)?;

    Ok(rt)
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let rt = open()?;

    let call_func: Function<(i32, i32, i32), i32> = rt.find_function("_call")?;
    let ret = call_func.call(0, 0, 0)?;
    assert_eq!(ret, 0);
    drop(call_func);

    Ok(())
}

where empty.wasm is empty.wasm.gz (but most WASM files should reproduce the problem).

Rework the function object api

The current definition of a wasm3 function is

#[derive(Debug, Copy, Clone)]
pub struct Function<'rt, ARGS, RET> {
    raw: NNM3Function,
    rt: &'rt Runtime,
    _pd: PhantomData<(ARGS, RET)>,
}

which means a function once looked up borrows the runtime for its entire lifetime. This pretty much forces the implementation to make use of interior mutability since repeatedly looking up functions isn't really something anyone would want to do. This also means there are a lot of aliasing problems in regards of accessing memory and the stack since returning slices to them would mean that one could invalidate those by simply calling a function object.
One idea that I now had is to replace function objects with tokens that have to be passed to the runtime to call them. This means instead of being able to call them like func.call(130, 14.0) one would call a func with the following syntax runtime.call(func, (130, 14.0)) or func.call(&mut runtime, 130, 14.0). This would allow us to make use of rust's linear types and compile time safety to a better degree.
Another solution would be to use interior mutability via RefCells resulting in panics in case the memory is borrowed while a function is being called.

All of this only really matters if the user has access to the stack and memory though. The stack should probably be hidden from a user anyways(or be inherently unsafe to use) but I am not sure about how to handle the raw memory. So this requires a bit more thinking.

A crude implementation of the token based idea exists in #5

wasm3 support for arm64 (Apple Silicon, M1)

wasm3-rc won't compile on new aarch64/arm64 target. Here's the error:

Updating crates.io index
Compiling cc v1.0.66
Compiling shlex v0.1.1
Compiling cty v0.2.1
Compiling wasm3-sys v0.1.2 (/Users/wesleyhales/dev/wasm3-rs/wasm3-sys)
error: failed to run custom build command for wasm3-sys v0.1.2 (/Users/wesleyhales/dev/wasm3-rs/wasm3-sys)

Caused by:
process didn't exit successfully: /Users/wesleyhales/dev/wasm3-rs/target/debug/build/wasm3-sys-993c8d824c535d4d/build-script-build (exit code: 101)
--- stderr
thread 'main' panicked at 'failed to read wasm3/source directory', wasm3-sys/build.rs:22:29
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

I originally reported the issue here... see comments on why I brought it to this repo.

I tried to build wasm3 standalone and there are issues with unrecognized flags on arm64. After running cmake, I had to edit the build file to remove the -march=native flag completely and replace -fuse-ld=lld with -fuse-ld=ld. wasm3 successfully built after these changes.

Update Wasm3, make use of exciting new API

With latest Wasm3 (v0.5.0), new API is available which fixes many things in the public API:

Exported function signature introspection
Introspection of imported functions (see _ctx argument)
Public api for calls with raw arguments (instead of strings)
Public API to get return values
Support recursive m3_Call invocation. I.e. calling exported function from within imported function callback.
m3_RunStart can be used to force the module initialization.

I think all this can greatly help your bindings implementation.
@Veykril please let me know it you need any other public API, or have any ideas!

This is already implemented in Python bindings, you can use it as a reference:
https://github.com/wasm3/wasm3/blob/master/platforms/python/m3module.c

doesn't compile

Hey,

I was trying to use it and I got:

error: failed to run custom build command for `wasm3-sys v0.1.1 (https://github.com/Veykril/wasm3-rs#7a5199ef)`

Caused by:
  process didn't exit successfully: `/home/scop/Documents/workspace/release/build/wasm3-sys-9fe8ce7aeab78f43/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to generate bindings: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/scop/.cargo/git/checkouts/wasm3-rs-136514b8b4045c53/7a5199e/wasm3-sys/build.rs:78:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I've tried both:

wasm3 = { git = "https://github.com/Veykril/wasm3-rs" }
# and using
wasm3 = "0.1.1"

Is there a way to override STDOUT for WASI?

It would be nice to be able to specify a location to write to STDOUT so that the calling process can capture STDOUT. Is that something that is possible?

Support wasm3 compile flags

With #21 one can pass the propert clang flags in order to set the compilation flags in https://github.com/wasm3/wasm3/blob/master/source/m3_config.h, for instance:

BINDGEN_EXTRA_CLANG_ARGS="--sysroot=/usr/local/opt/gcc-arm-none-eabi/arm-none-eabi -Dd_m3HasFloat=0" cargo build

Currently passing -Dd_m3HasFloat=0 results in this error because the wasm3 signature changes:

error[E0061]: this function takes 4 arguments but 5 arguments were supplied
   --> /Users/jiayihu/Desktop/Repo/wasm3-rs/src/function.rs:185:13
    |
185 |             (*_pc.cast::<ffi::IM3Operation>()).expect("IM3Operation was null")(
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 4 arguments
186 |                 _pc.add(1),
    |                 ----------
187 |                 _sp,
    |                 ---
188 |                 _mem,
    |                 ----
189 |                 _r0,
    |                 ---
190 |                 _fp0,
    |                 ---- supplied 5 arguments

Passing d_m3FixedHeap, such as -Dd_m3FixedHeap=(8 * 1024), also results in compilation error because the (8 * 1024) syntax is not supported by #21 .

I just wanted to report the issues and causes for anyone interested. After being finally able to compile everything, I realized while I was implementing the intrinsics for calloc, free, realloc (required if d_m3FixedHeap is unset) that I was not very satisfied with the wasm3 implementation itself. Its C code is very hard to read and extend IMO. I'm ditching in favor of https://github.com/paritytech/wasmi or writing a WASM runtime myself.

Please publish v0.5.0 to crates.io

Please publish v0.5.0 to craetes.io, Thanks.
Now it seem only v0.3.1 on creates.io, however v0.3.1 can not support iOS because of this https://github.com/wasm3/wasm3/pull/48/files#

How to copy string to stack when sending to a function as argument?

I can pass string pass bidirectionally in the imported function because I can access the stack memory. But I don't know how to do it for exported function. I don't have access to the stack and can not implement ArgType for my type. Is there any way to do this?

Crash on f64 closure args

The following code crashes at the module::link_closure step:

use wasm3::{Module, CallContext};

type AudioPlayClosureType = dyn for<'cc> FnMut(&'cc CallContext, (i32, f64, f64, f64, f64)) -> () + 'static;

pub fn link_closures(module: &mut Module) -> Result<()> {
    let tmp = Box::new(make_audio_play());
    match module.link_closure::<(i32, f64, f64, f64, f64), (), Box<AudioPlayClosureType>>("env", "Engine_Audio_Play", tmp) {
        Ok(_) => {},
        Err(err) => info!("Could not link closure: {:?}", err),
    };
    Ok(())
}

fn make_audio_play() -> impl FnMut(&CallContext, (i32, f64, f64, f64, f64)) -> () {
    move |_ctx: &CallContext, args: (i32, f64, f64, f64, f64)| {
        let id = args.0;
        let px = args.1;
        let py = args.2;
        let pz = args.3;
        let volume = args.4;
        info!("Called play on id {:?} at pos ({:?},{:?},{:?}) with volume {:?}", id, px, py, pz, volume);
    }
}

The way I'm running this (compiled as a dll, loaded by a game written in Unity) it's hard to get a crash dump unfortunately, but I've tried various things and whenever there's f64s in the args it crashes, but with just i32s it runs fine.

why is there a inner pointer error?

#[derive(Copy, Clone, PartialEq, Eq)]
pub struct Wasm3Error(*const cty::c_char);

This contaminates error.

Can't compile with build-bindgen

I can't get to compile to crate in any way. I've installed clang from brew and also MacOS Xcode devtools, but if I use the build-bindgen features I get the following error:

Caused by:
  process didn't exit successfully: `/Users/jiayihu/Desktop/Repo/fedra-thesis/fedra/target/debug/build/wasm3-sys-c75d8740be89c22d/build-script-build` (exit code: 101)
  --- stderr
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/machine/types.h:37:2: error: architecture not supported
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list'
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types/_size_t.h:31:9: error: unknown type name '__darwin_size_t'
  fatal error: too many errors emitted, stopping now [-ferror-limit=]
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture, err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/machine/_types.h:34:2: error: architecture not supported, err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:55:9: error: unknown type name '__int64_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:56:9: error: unknown type name '__int32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:57:9: error: unknown type name '__int32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:60:9: error: unknown type name '__uint32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:61:9: error: unknown type name '__uint32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:62:9: error: unknown type name '__uint64_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:68:9: error: unknown type name '__darwin_natural_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:70:9: error: unknown type name '__uint16_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:71:9: error: unknown type name '__int64_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:72:9: error: unknown type name '__int32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:73:9: error: unknown type name '__uint32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:74:9: error: unknown type name '__int32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:75:9: error: unknown type name '__uint32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types.h:76:9: error: unknown type name '__uint32_t', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/machine/types.h:37:2: error: architecture not supported, err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types/_va_list.h:32:9: error: unknown type name '__darwin_va_list', err: true
  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/sys/_types/_size_t.h:31:9: error: unknown type name '__darwin_size_t', err: true
  fatal error: too many errors emitted, stopping now [-ferror-limit=], err: true
  thread 'main' panicked at 'Failed to generate bindings: ()', /Users/jiayihu/.cargo/registry/src/github.com-1ecc6299db9ec823/wasm3-sys-0.1.2/build.rs:121:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Trying instead to compile it without the bindgen feature results in the following error:

error: failed to run custom build command for `wasm3-sys v0.1.2`

Caused by:
  process didn't exit successfully: `/Users/jiayihu/Desktop/Repo/fedra-thesis/fedra/target/debug/build/wasm3-sys-ed19931fe417e3c8/build-script-build` (exit code: 101)
  --- stderr
  wasm3/source/m3_core.h:11:10: fatal error: 'stdio.h' file not found
  wasm3/source/m3_core.h:11:10: fatal error: 'stdio.h' file not found, err: true
  thread 'main' panicked at 'Unable to generate bindings: ()', /Users/jiayihu/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.55.1/src/main.rs:54:36
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  thread 'main' panicked at 'Failed to run bindgen: ExitStatus(ExitStatus(256))', /Users/jiayihu/.cargo/registry/src/github.com-1ecc6299db9ec823/wasm3-sys-0.1.2/build.rs:80:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I've also tried to just run clang -v a.c where a.c contains only an include of stdio.h and it works without issue, meaning it's able to find the header file. So the issue is in rust bindgen or something in this crate I suppose.

Unable to generate bindings

Having the following issue while cargo install:

error: failed to run custom build command for `wasm3-sys v0.3.0`

Caused by:
  process didn't exit successfully: `C:\Users\Intel\AppData\Local\Temp\cargo-installZQzJUm\release\build\wasm3-sys-403977a41458bc68\build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'Unable to generate bindings: Error { kind: NotFound, message: "program not found" }', C:\Users\Intel\.cargo\registry\src\github.com-1ecc6299db9ec823\wasm3-sys-0.3.0\build.rs:78:35
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `hotg-rune-cli v0.11.3`, intermediate artifacts can be found at `C:\Users\Intel\AppData\Local\Temp\cargo-installZQzJUm`

Caused by:
  build failed

Environment: Windows 10 Pro

All other cargo install works well...

wasm3-sys doesn't work on Windows?

Hello world sample

I'm struggling to find the right functions to call to make this work. I'd love to see a sample that utilizes the Rust bindings that:

supports namespaced imports (call a namespace-prefixed host function from inside wasm)
supports exports (call a wasm function from the host)
supports WASI (e.g. see a println!() work while under host interpretation.

If there are some docs or some other source of information you can point me at, I can take a stab at this.

ESP32-C3 Support

Has anybody had luck running this on the esp32-c3? It seems possible but I'm not getting very far. The two stumpers I'm getting are this one:

  process didn't exit successfully: `C:/temp/idf\debug\build\wasm3-sys-9e0a6fa44c575681\build-script-build` (exit code: 101)
  --- stderr
  error: unknown target triple 'riscv32imc-esp-espidf', please use -triple or -arch
  thread 'main' panicked at 'libclang error; possible causes include:
  - Invalid flag syntax
  - Unrecognized flags
  - Invalid flag arguments
  - File I/O errors
  - Host vs. target architecture mismatch
  If you encounter an error missing from this list, please file an issue or a PR!', C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\bindgen-0.61.0\ir\context.rs:524:13

And this one:

error[E0425]: cannot find value `X_OK` in crate `libc`
   --> C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\clang-sys-1.4.0\src\support.rs:163:51    
    |
163 |     unsafe { Ok(libc::access(path.as_ptr(), libc::X_OK) == 0) }
    |                                                   ^^^^ not found in `libc`

error: could not compile `clang-sys` due to previous error

Any pointers in the right direction would b greatly appreciated.

CallContext should be branded with a lifetime

Currently it might be possible to move it out of the linked closure which can wreak havoc.

Replace the Runtime references in Module and Function

Instead we should just use plain old Rc. This will simplify things a lot as currently it is basically impossible to store Functions and Modules, requiring to constantly query for them when needed which is quite a performance hit.