-
Notifications
You must be signed in to change notification settings - Fork 13.3k
WASM module base address is always 0, prevents multiple modules with single imported memory #46645
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
Comments
I believe this is now configurable with LLD as the default linker, so closing |
Adding a pointer for future readers: #48125 (comment)
|
So this doesn't seem to be fixed, but is probably better served by llvm/lld's issue tracker anyway. |
@Arnavion oh I know for a fact that For me though
|
Ah. It doesn't work when you combine it with |
I dumped the WASM structures and now I see that Edit: And it makes sense why |
I was struggling to get It looks like, in the latest
My solution (as I needed to get my globals to be below 65536) was to change the size of the stack, using the
|
Every wasm module's base address currently defaults to 0 with no way for the crate to override it. This means multiple modules compiled with
#![wasm_import_memory]
can't use a single imported memory without clobbering each other's data.Does it make sense to add a crate attribute like
#![wasm_base_address(100)]
to set that module's base address in binaryen's options to100
? This does mean that the user will have to manually update every crate's base address according to the base addresses of every other crate. So this doesn't work for crates they don't own [1].The proper solution would be for the compiler to emit relocation information so that a post-processor like
wasm-gc
or a loader in the host environment can relocate the modules. As of now that isn't possible, since pointers to static data are indistinguishable from integers.[1]: Doesn't work for top-level crates (that compile into WASM modules) they don't own that is. rlib dependency crates are fine.
The text was updated successfully, but these errors were encountered: