mirror of
https://github.com/rust-lang/rust.git
synced 2026-05-07 00:51:14 -04:00
Jacob Pratt
b594ef31e9
Wasm: remove implicit `__heap_base`/`__data_end` exports This is kind of a follow-up to rust-lang/rust#147225. Currently `__heap_base`/`__data_end` globals are implicitly exported on `wasm*-unknown-unknown` and `wasm32v1-none`, even though they were only used for Wasm multi-threading, requiring the atomics target feature and shared memory. Instead users should explicitly opt-in to these features, in which case toolchains, like `wasm-bindgen`, would require some linker flags. After this PR the following would be required for multi-threading support in `wasm-bindgen`: ``` -Clink-arg=--shared-memory -Clink-arg=--max-memory=1073741824 -Clink-arg=--import-memory -Clink-arg=--export=__heap_base -Clink-arg=--export=__wasm_init_tls -Clink-arg=--export=__tls_size -Clink-arg=--export=__tls_align -Clink-arg=--export=__tls_base ``` You will notice that the only new addition is `--export=__heap_base`, apparently `wasm-bindgen` doesn't need `__data_end` anymore (I didn't dig into the original motivation). --- For context why `wasm-bindgen` needed access to `__heap_base`: There is currently no mechanism in the Wasm tool conventions that automatically allocates the stack for every thread (e.g. via the `start` function). So `wasm-bindgen` has to explicitly call `malloc` to allocate the stack on the new thread. However, calling `malloc` itself requires a stack to be present! With the help of `__heap_base` `wasm-bindgen` constructs a temporary stack to make this work. This is obviously quite hacky. A newer implementation could go a different route: e.g. allocate the threads stack in the main thread and passing the right information on, not requiring access to `__heap_base` at all (and avoiding this really messy workaround). I should also note here that e.g. [`js-bindgen`](https://github.com/wasm-bindgen/js-bindgen), the successor currently being worked on, doesn't need any of these exports because it doesn't rely on post-processing. In which case all of these variables can be accessed by name at link-time, instead of requiring the linker to export each variable for post-processing to find them by name. That is to say: all these workaround are toolchain-specific and not universal to the Wasm targets. --- r? @alexcrichton
Please read the rustc-dev-guide chapter on Backend Agnostic Codegen.