When I started using resources I assumed that it would be mostly symmetric for guest import and export, but I just learned about the need for canon resource.new
, .rep
and .drop
in a strangely named [exports]ns
module, which is only used for exported resources. Also when calling a [method]
guest import passes ids (s32), but export receives the rep (likely s64 with wasm64).
Now I found [resource-drop]type
(guest import) vs [dtor]type
(guest export) but struggle to find a description. As Rust and C bindgen disagree here, I tend to follow Rust, but a document link would be most helpful.
Naming of symbols and such doesn't currently have documentation as it's "just" a convention of the wit-component
tool which turns core wasms into components. That's not part of any standard at this time, but we've had historical talk of it becoming more standardized in the future.
likely s64 with wasm64
Note that this is not currently the case, the rep
of resources only supports the wasm i32 type right now, i64 is not supported.
As Rust and C bindgen disagree here
Do you have an example of where they disagree? That's probably a bug...
As for the symbol names, I can try to at least explain this briefly here:
[export]
"mangling" since you can import and export the same interface.[resource-drop]...
function is the canon resource.drop
intrinsic[resource-new]...
function is the canon resource.new
intrinsic.[resource-rep]...
For more information about what those intrinsics to you'd want to consult the canonical abi documentation
Alex Crichton said:
likely s64 with wasm64
Note that this is not currently the case, the
rep
of resources only supports the wasm i32 type right now, i64 is not supported.
Because it is so hard to distinguish rep and id, as both map to i32, I went for the hypothetical wasm64 rep of usize/i64 to tell rep and id apart. (In parallel I work on supporting wasm64, but that is a larger and separate task)
As Rust and C bindgen disagree here
Do you have an example of where they disagree? That's probably a bug...
At first I thought that only Rust bindgen exports the [dtor]
symbol for guest defined resources, because the [resource-drop]
symbol is easier to spot. Now I found that C bindgen defines [dtor]
which, if I guess correctly, should call the [export]ns
[resource-drop]type
function to deregister the resource by its id from the host.
But the C bindgen calls the non-[export]
resource-drop from both __wasm_import_test_example_my_interface_my_object_drop
and __wasm_import_exports_test_example_my_interface_my_object_drop
. So I guess the second one should refer to the [export]
function.
__attribute__((__import_module__("test:example/my-interface"), __import_name__("[resource-drop]my-object")))
extern void __wasm_import_test_example_my_interface_my_object_drop(int32_t handle);
void test_example_my_interface_my_object_drop_own(test_example_my_interface_own_my_object_t handle) {
__wasm_import_test_example_my_interface_my_object_drop(handle.__handle);
}
__attribute__((__import_module__("test:example/my-interface"), __import_name__("[resource-drop]my-object")))
extern void __wasm_import_exports_test_example_my_interface_my_object_drop(int32_t handle);
void exports_test_example_my_interface_my_object_drop_own(exports_test_example_my_interface_own_my_object_t handle) {
__wasm_import_exports_test_example_my_interface_my_object_drop(handle.__handle);
}
Ah good point! That looks like a bug in the C generator yeah
Alex Crichton said:
As for the symbol names, I can try to at least explain this briefly here:
For more information about what those intrinsics to you'd want to consult the canonical abi documentation
This symmetry-at-first-glance confused me because these functions are not defined by the guest. The undocumented? [dtor]
- which isn't even type symmetric (dtor gets rep, ctor returns id, both with good reasons) to the [constructor]
confused me at first. Now having studied Rust and C codegen I am confident that I can re-implement it right for C++.
By the way, seeing [dtor]
next to [constructor]
looks odd to me. :wink:
So that inconsistency should probably get fixed before standardizing it, unless the existence of WASI 0.2 has already made this a de-facto standard …
Last updated: Dec 23 2024 at 12:05 UTC