From ba116d65cc5d8079d4ec189d861891fcc39776a1 Mon Sep 17 00:00:00 2001 From: YAMAMOTO Takashi Date: Wed, 5 Jun 2024 13:21:32 +0900 Subject: [PATCH 1/2] Mention an alternative approach for toolchains cf. https://github.com/WebAssembly/custom-page-sizes/issues/21 --- proposals/custom-page-sizes/Overview.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/proposals/custom-page-sizes/Overview.md b/proposals/custom-page-sizes/Overview.md index 5bd8f31..aabda61 100644 --- a/proposals/custom-page-sizes/Overview.md +++ b/proposals/custom-page-sizes/Overview.md @@ -358,6 +358,30 @@ This approach has the following benefits: [imagine]: https://github.com/WebAssembly/custom-page-sizes/issues/3 +#### Alternative: use an immutable global instead of the relocations + +Alternativey, we can probably use an immutable global instead of +the relocations. + +Pros over relocations: + +- The toolchain implementations might be more straightforward that way. +- A global can be exported/imported. It might be simpler for things like + [dynamic-linking]. +- The resulted binary might be more friendly to binary-rewriters like + wasm-opt. + +A possible downside is that you can't have the page size in data sections. +Eg. consider a C global variable like the following. +It shouldn't be a big problem these days as modern applications do not +assume that the page size is a build-time constant anyway though. + +```c +static int global_var = PAGE_SIZE; +``` + +[dynamic-linking]: https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md + ### How This Proposal Satisfies the Motivating Use Cases 1. Does this proposal help Wasm better target resource-constrained environments, From dc25dd3f23d88ffdc64f81bd170bdbc1af261c42 Mon Sep 17 00:00:00 2001 From: Nick Fitzgerald Date: Tue, 11 Jun 2024 11:59:05 -0700 Subject: [PATCH 2/2] Editorial tweaks and rewording to alternative tooling approach --- proposals/custom-page-sizes/Overview.md | 33 ++++++++----------------- 1 file changed, 10 insertions(+), 23 deletions(-) diff --git a/proposals/custom-page-sizes/Overview.md b/proposals/custom-page-sizes/Overview.md index aabda61..0c9f014 100644 --- a/proposals/custom-page-sizes/Overview.md +++ b/proposals/custom-page-sizes/Overview.md @@ -358,29 +358,16 @@ This approach has the following benefits: [imagine]: https://github.com/WebAssembly/custom-page-sizes/issues/3 -#### Alternative: use an immutable global instead of the relocations - -Alternativey, we can probably use an immutable global instead of -the relocations. - -Pros over relocations: - -- The toolchain implementations might be more straightforward that way. -- A global can be exported/imported. It might be simpler for things like - [dynamic-linking]. -- The resulted binary might be more friendly to binary-rewriters like - wasm-opt. - -A possible downside is that you can't have the page size in data sections. -Eg. consider a C global variable like the following. -It shouldn't be a big problem these days as modern applications do not -assume that the page size is a build-time constant anyway though. - -```c -static int global_var = PAGE_SIZE; -``` - -[dynamic-linking]: https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md +Alternatively, the linker could inject an immutable global defining the page +size and relocate uses of the `__builtin_wasm_page_size()` to `global.get +$injected_page_size_global` instead of `i32.const $page_size`. This is mostly +equivalent, and should not fundamentally have any more or less potential for +optimization by the Wasm consumer, but may allow [dynamic linking] to either +assert an expected page size (to double check against dynamic linking errors at +runtime) or even for a shared library module to be compatibly linked with +modules using any page size. + +[dynamic linking]: https://github.com/WebAssembly/tool-conventions/blob/main/DynamicLinking.md ### How This Proposal Satisfies the Motivating Use Cases