Open kateinoigakukun opened 1 year ago
To link extension libraries dynamically we need some extra ABI convention on the top of Wasm's import/export and Component Model. Extra requirements on top of the existing ABI to make the extension libraries work with CRuby convention are:
rb_define_method
and the registered functions are called from CRuby VM. The main module, CRuby VM, does not know what functions are exported from extension libraries at the moment of building it, so calls to extension libraries cannot be direct.Note that I intentionally ignored dlopen
or dlsym
because they are essentially unnecessary if the linked modules can be known at the componentizing time.
Thus conventions to be decided here are:
Emscripten's dynamic linking ABI would be useful as a starting point, but it requires external loader to fixup the addresses in code section. IIUC the main reason why it requires external loader is that Wasm cannot self-patch code space. (maybe also for resolving symbols at runtime?)
But I don't have well understanding for "lifting" yet, so maybe I'm missing something key feature in Component Model
Related links:
Not for generic extension library, but it looks reasonable approach for importing/exposing functions https://github.com/dicej/componentize-py/
This is something I'd be interested in doing, but I'm not sure where to start? I'm working project that'll be using wasm for plugins and I'd like to support running ruby as that's what most people using the project will be familiar with. I'd be more than happy to make something like https://github.com/dicej/componentize-py/ and maintain it for the wider ruby community
See https://github.com/WebAssembly/component-model for more details about Component Model