Passing arguments while calling exported functions

[pepyakin]

To call an exported function we need to be able to pass arguments to it. I have a two straw man approaches to implement that.

The first one: pass arguments dynamically. That is, every exported function should have a thunk generated. This thunk reads all arguments from the dynamic list of argument values (a-la wasmi's RuntimeValue) and then call into the original function with the whatever ABI it has. Upon calling the exported function, we check that the argument slice matches the signature and then call we call the thunk with the fixed signature (vmctx, args_ptr). This thunk could also convert and write the return value to the specifc pre-allocated location in the callee. Dumb but easy.

The second one. Generate exported functions with the specific ABI, say system_v. Then introduce an argument wrapper trait.

unsafe trait ArgsWrapper {
  fn signature() → WasmSignature;

  fn call(fn_ptr: usize, vmctx: usize, args: Self);
}

This trait's main purpose is to provide a way to get the signature dynamically and unpack the values for the actual call. We can generate impls for this trait by a macro. Here is an example impl for function with arity 2.

unsafe impl<A: HasWasmType, B: HasWasmType> ArgsWrapper for (A, B) {
  fn signature() → WasmSignature {
    WasmSignature::new(&[A::wasm_type(), B::wasm_type()])
  }
  unsafe fn call(fn_ptr: usize, vmctx: usize, args: (A, B)) {
    let (a1, a2) = args;
    let f = fn_ptr as extern "C" fn(usize, A, B);
    unsafe {
      f(vmctx, a1, a2)
    }
  }
}

Then actual call can be implemented as following:

fn call<A: ArgsWrapper >(func_name: &str, args: A) {
  let wasm_func = self.funcs.get(func_name).unwrap();
  assert_eq!(wasm_func.signature, A::signature());
  unsafe { A::call(wasm_func.ptr, args) }
}

I think this approach can be scaled to handle returning values as well.

@sunfishcode what do you think? Am I missing something, do you have better proposals?

[sunfishcode]

Sorry for the late response here! I've been busy and somehow lost track of this issue.

My general preference would be for the second approach. Cranelift has system_v and windows_fastcall specifically to allow it to implement platform-native calling conventions, and I think it makes sense to take advantage of that here. I like the idea of using a helper function like this to wrap up the unsafe code and the vmctx argument.

[sunfishcode]

I've now implemented an approach where in we use the JIT to generate trampoline functions. We store the argument values onto the stack, the trampoline function loads them and makes the call, and then stores the return values onto the stack. Take a look at trampoline_park.rs for details, or just use InstancePlus and call invoke as desired :-).