-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support tuple return type (multi-value feature) #156
Comments
Please check other development language. For example C/C++ |
* feat: add #[callable_point] proc macro * feat: add #[dynamic_link] proc macro * fix: publiclize the memory module using in #[callable_point] and #[dynamic_link] * feat: add re-exports #[callable_point] and #[dynamic_link] * feat: make tuple return by #[callable_point] and #[dynamic_link] * feat: add copies region of args and return between env The actual copy calls are executed by wasmvm. * fix: disable return the tuple type #156 * refactor: improve error handling with proc_macro_error * feat: update sample contract for dynamic_link * test: add unit test for copy_region_vals_between_env * test: add integration test for callable_point macro proc_macro cannot do normal unit tests. Instead, it is replaced by the contract's integration test. * test: add integration test for dynamic_link macro proc_macro cannot do normal unit tests. Instead, it is replaced by the contract's integration test. * fix: unlimit the target_arch of memory module When running the test with dynamic_link proc_macro, it should be able to compile the memory module on other architectures as well. * chore: cargo fmt * chore: update cargo.lock for contracts * fix: fix maximum size * chore: cargo clippy * test: add module name test condition for dynamic_link macro * chore: fix reverted unused warnings in the contracts * chore: fix typo * chore: remove unnecessary prefix * refactor: improve abort message * refactor: change to use quote! and proc_macro2 proc_macro2 allows the implementation of separate modules. * chore: update cargo.lock * chore: disable clippy warning for abort_by! * fix: add disallowed type by parameter see: #152 * chore:cargo fmt * chore: avoid false-positive of clippy * chore: again avoid clippy * chore: fix typo
This issue was reviewed before the introduction of proc macros #[callable_point] and #[dynamic_link], when primitive types were delivered as they are. But now it is passed through serialization by the above proc macro. Therefore, it can be expected that a tuple can also be passed as a single serialized data. It is necessary to check whether the tuple type is available by serialization. |
closed via #195 |
Problem
When compiling a tuple return function as shown below, wasm function is created to be passed as a
param
.rust:
fn return_tuple() -> (u64, u128)
WAT:
(func $return_tuple (type $t6) (param $p0 i32)
A single return is passed as
result
like this:rust:
fn return_single() -> u64
WAT:
(func $stub_return_single (type $t12) (result i32)
If the tuple return is passed as a single param, it is impossible to identify it on the vm host side and copy the region.
Solution
https://hacks.mozilla.org/2019/11/multi-value-all-the-wasm/
This can be solved using wasm's multi-value feature.
RUSTFLAGS="-C target-feature=+multivalue"
We can expect to create a multi value return like this:
WAT:
func $return_tuple (type $t6) (result i32 i32)
Problem of Solution
There are two problems.
.../release/deps/libuuid-462c11271c01b650.rmeta -C target-feature=+multivalue`` (signal: 11, SIGSEGV: invalid memory reference)
https://github.com/wasmerio/wasmer/blob/9291c27941f15a2446be603a5f64f716bf321361/lib/compiler-singlepass/src/compiler.rs#L80
The text was updated successfully, but these errors were encountered: