Hi, folks. for various reasons, I dropped work on my wasmtime-java integration, but am picking it back up now. Some tests that were working before have now stopped working, and it looks like something changed in the Rust -> WASM compilation in regards to mutable pointers (byte array out params). Basically, generated WASM import declarations are not generating the i32 input param for that field. Do folks know if something changed in a recent(ish) version of rustc/llvm that might have broken this? Thanks!
I updated everything to current stable releases for reference...
Here's an example, the response
param doesn't end up in the generated wasm interface: https://github.com/bluejekyll/wasmtime-java/blob/main/tests/strings/src/lib.rs#L6
You might be running into how the wasm32-wasi target had its ABI updated to match C perhaps? Do you have the signature of the function in question?
ah yeah that's the ABI update, the first argument is now passed indirectly on the wasi target rather than by-value as two params
(assuming WasmSlice is two u32 values)
Yes, WasmSlice is two u32's
We we can't do repr(C) type params (anymore)?
you can, the ABI is just different
clang decided that the ABI for any aggregate parameter is for it to be passed indirectly
Also, this RFC is highly relevant: https://github.com/bytecodealliance/rfcs/pull/11
It'll be a bit until it's fully finalized and implemented, but not that long either
oh I don't think this affects the problem @Benjamin Fry is running into, I think it's about compiling Rust to wasm instead
Alex Crichton said:
you can, the ABI is just different
Do you perhaps have a link to an example?
there's an upstream issue about this ABI detail as well -- https://github.com/WebAssembly/tool-conventions/issues/88
the funtion you have there is translated to (import "test" "say_hello_to_java" (func (param i32 i32)))
where the first i32
points to memory where there's two consecutive i32
values, and the second i32
is the return pointer from the signature
oh, right. The part I was referring to was this:
for various reasons, I dropped work on my wasmtime-java integration, but am picking it back up now.
oh heh indeed it is highly relevant for that part :)
similarly for your greet
function that gets translated to (export "greet" (func (param i32)))
which means that to call the greet
function you first have to allocate space for the WasmSlice
struct in memory, then fill in the struct, then pass the pointer
Yeah, I understand the issue now, thanks, @Alex Crichton
Is the best bet to expand these to the exact ABI, and not try and do the direct inline types then?
depends on your use case, but the answer is probably "yes"
Thanks, @Alex Crichton that was the exact issue. I really appreciate the quick feedback. I owe you a drink at next RustConf.
Last updated: Nov 22 2024 at 16:03 UTC