-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WASM support #6
Comments
I've been playing around with this a bit! It looks promising, but like there also might be other issues. One is that
Not the end of the world, but this would currently prevent |
I was doing some research on how to tackle that issue. Unfortunately without success, but i've found many potential ways to get just a bit closer to solutions. It seems like there is a relocation support for wasm custom sections in lld, this mechanism is unfortunately not utilized by Additionally, because custom sections are stored in not addressable program metadata, having actual data stored there directly means it's no longer mutable. In other platforms, the distributed slice is literally aliasing the memory of individual static declarations. On wasm, there would have to be a separate copy of all data (in fact three total - individual statics, link section data and copy owned by distributed slice). My guess is that there could be a way to retreive the addresses of those statics at runtime, then reference those with Alternatively, we could leverage the |
Has there been any update on the blockers for this? This would come in extremely handy. |
@dtolnay What's your opinion on the right direction to go here? It seems like there are two options from @Frizi's comment:
It seems like this may be a dichotomy, unless there's a third (or nth) option that you see available? |
Neither of those is appropriate for this crate. |
Thanks, sorry, I was a bit confused about the future of the inventory crate, given that there's an issue for typetag to migrate to it. |
From my understanding, there are two directions forward for typetag on WASM:
I believe the typetag issue for switching to linkme - dtolnay/typetag#15 - is predicated on the assumption that 2 is preferable (and possibly easier) than 1. I believe it is preferable if possible: it doesn't require encoding life-before-main into rustc proper, and is thus cleaner. Unfortunately, I think the small print for 2. makes it potentially much harder to implement: based on This option is interesting to me:
Can we currently write code which does this? Specifically, can we do this without CTORs? (as CTORs aren't available on WASM) I think it would belong in The blocker here in my understanding isn't where things belong - it's getting anything to gather pointers from around a program without explicitly being called. There's no support for CTORs on WASM with rustc, and no support for properly linking pointers into custom sections on WASM either. |
I am closing this issue because it hasn't turned out to be actionable in this crate. This comment has a writeup of what would be the next step for a rust compiler+library or compiler+language RFC to do distributed slices in the compiler instead of linker. |
I investigated if it would be possible to add WASM support and it looks like there might be a way. While I have not found a similar start/end convention that works, WASM supports custom data sections which can be accessed as an array from JS.
wasm_bindgen
has a hidden and somewhat unsupported function that can get a handle to the WebAssembly.Module, whilejs-sys
exposes bindings for fetching data from a custom section. This code compiles:@ibaryshnikov created a more complete and runnable example here:
https://github.com/ibaryshnikov/wasm-custom-sections/blob/master/src/lib.rs
Unfortunately, webpack does not expose the WebAssembly.Module object in javascript:
webpack/webpack#8157
Here's another similar issue:
WebAssembly/esm-integration#14
So this approach seems to work, but the WebAssembly.Module handle is not exposed in certain cases. Better than nothing I guess? 😁
The text was updated successfully, but these errors were encountered: