I made two components using cargo-component here, one in the big
folder and one in the hello
folder. https://github.com/macovedj/builder-examples
I also used wasmbuilder to link them with the following diagram
Screenshot-2023-05-11-at-4.30.18-PM.png
I ran this jco command: jco transpile big-greet.wasm --map 'wasi-*=@bytecodealliance/preview2-shim/*' -o big-greet
It's been a bit since I used jco, so I'm guessing that's where the issue is, but there were a lot of steps so not totally sure where I went wrong, I got the following error. Would love to debug on my own, but I'm not sure how to use the error to figure out which thing I'm missing an implementation for. I would expect the map
flag to provide all of the wasi interfaces that are needed. Any help is greatly appreciated, but I realize this might be a bit on the complicated side... Happy to provide more info I missed.
panicked at 'not implemented', crates/js-component-bindgen/src/bindgen.rs:1029:49
(jsct transpile) RuntimeError: unreachable
at __rust_start_panic (wasm://wasm/0122631e:wasm-function[3490]:0x1fdc92)
at rust_panic (wasm://wasm/0122631e:wasm-function[3486]:0x1fdc3f)
at _ZN3std9panicking20rust_panic_with_hook17h1e5f3993ce22fe2aE (wasm://wasm/0122631e:wasm-function[3485]:0x1fdc0f)
at _ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h757395b3caa1a881E (wasm://wasm/0122631e:wasm-function[3471]:0x1fcbd6)
at _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h3e911ea98537fbdbE (wasm://wasm/0122631e:wasm-function[3470]:0x1fcb38)
at rust_begin_unwind (wasm://wasm/0122631e:wasm-function[3480]:0x1fd866)
at _ZN4core9panicking9panic_fmt17he9c46855d60d636eE (wasm://wasm/0122631e:wasm-function[3604]:0x206c27)
at _ZN4core9panicking5panic17hf333278c14c20b5eE (wasm://wasm/0122631e:wasm-function[3610]:0x207190)
at _ZN20js_component_bindgen7bindgen9JsBindgen11instantiate17hfe4cbb5545331156E (wasm://wasm/0122631e:wasm-function[101]:0xf8e0)
at _ZN20js_component_bindgen9component8generate17h2fb6336405b47ca9E (wasm://wasm/0122631e:wasm-function[198]:0x280ae)
After some thought, I'll try and use a locally built jco
to log out whatever implementation was expected
Ah, looks like I need an implementation of this https://github.com/bytecodealliance/jco/blob/main/crates/js-component-bindgen/src/transpile_bindgen.rs#L350
@Daniel Macovei are you definitely using different string encodings between inputs and outputs of the component?
we can definitely add transcoding support, was just waiting for it to be needed
feel free to post an issue!
I would have guessed not since I'm using cargo-component
to create each component. Will dig in a little bit tomorrow and likely post something. Thanks!
I don't have a huge need or anything. Was mostly just trying to play with the wasmbuilder app using the simplest imports and exports I could think of. One component just exports a hello world function, and the other imports that greeting and uppercases it
if you're able to share the generated component in a jco issue it would be good to look into the exact scenario further
I opened this this morning. Working on a few things, but I also intend to look into this myself. https://github.com/bytecodealliance/jco/issues/75
fwiw when building locally, it looks like the very first wasm export that gets called by js is generate
from js-component-bindgen-component
. In the bindings for that component, it looks like it fails as soon as it calls into the generate
function. Seems like a surprise to me because I thought the issue wouldn't happen until instantiate
gets called, but I can't even log anything from the very first line of generate
. I may not be building correctly, but I think I am. Have gone through most of the build scripts defined in the package.json
I made some passthrough functions for some of the unimplemented logic for transcoding and instance flags. This way I was able to transpile without getting an error, but obviously had some issues in my bindings. This is what gets fed to instantiateCore
in the result bindings, which appears to just be an alias of WebAssembly.instantiate
. Was looking for flags
and transcode
fields in the mdn docs on WebAssembly.instantiate
, and I'm guessing that these fields aren't used by WebAssembly.instantiate
? Instead instantiateCore
will get logic that calls WebAssembly.instantiate
in different ways, depending on the field values? Happy to try and help out here if I've got an accurate perception of what needs doing.
({ exports: exports7 } = await instantiateCore(await module8, {
callee: {
adapter0: exports1['hello-world'],
},
flags: {
instance1: ,
instance2: ,
},
memory: {
'': exports5.memory,
},
post_return: {
adapter0: exports1['cabi_post_hello-world'],
},
realloc: {
'': exports5.cabi_realloc,
},
transcode: {
'utf8-to-utf8 (mem0 => mem1)': ,
'utf8-to-utf8 (mem1 => mem0)': ,
},
}));
@Daniel Macovei I believe this will involve authoring some kind of createTranscoder(fromMem, toMem, encoding) => function (fromPtr, fromLen, toRealloc)
intrinsic that returns a function with the core signature expected by the transcoding adapter. Where JS code would then do the memory copy in this case. I'm not sure the exact core signature or how the realloc function index is passed.
if you want to create a draft PR with your work on stubbing out the implementation errors happy to collaborate on it as well
Happy to! At the moment the stubs basically just print debug statements and return empty strings, but I can still push it up
just having a test case wired in would be a huge help
https://github.com/bytecodealliance/jco/pull/76
Was considering pulling the components themselves into the repo, but didn't want to clutter things. Kindof tricky describing an issue across repos, but I think I provided all the links needed.
Last updated: Nov 22 2024 at 16:03 UTC