Risto (Aug 11 2020 at 14:51): Risto (Aug 11 2020 at 14:51):It seems that a module I test with imports env::__stack_pointer. How do I obtain this value? It seems that none of the modules I have export it or define the value in custom sections.
bjorn3 (Aug 12 2020 at 05:35):@Risto env::__stack_pointer is created by the linker. It only exists in the final linked wasm module.
Risto (Aug 12 2020 at 09:53):It seems that if I define a stack for a program it will be compiled with a stack.
However, the stack size isn't exported by llvm/clang even if one is defined.
The command I used to compile the module that should define the stack is
$CC example.c -o example.wasm -Wl,-no-entry,--allow-undefined,-zstack-size=1600,--import-table,--import-memory,--stack-first
Using wasi-sdk, so the compile target should be set to wasm-wasi automatically.
Risto (Aug 12 2020 at 11:22):Even if --export-all is passed to the linker, there is no exported value that signals the position or size of the stack. Many other variables are exported though, for example __memory_base. Unsure if I am missing something from the linking step. Hmm.
Yury Delendik (Aug 12 2020 at 13:48):does any of the compiled "example.wasm" functions needs __stack_pointer ?
Yury Delendik (Aug 12 2020 at 13:57):/me tried locally -- the global is not exported indeed
Risto (Aug 12 2020 at 14:12):@Yury Delendik No, it is not used I would say as far as I see.
I tried --export,__stack_pointer,--export,__stack_base, but they do nothing - no error or export. The export switch works for all other values, such as __memory_base or unused functions.
There is also no way to calculate/get the initial value for it either as far as I see, as there is no information on the location or size of the stack even if it is created to the module as stack-size and stack-first options dictate.
Yury Delendik (Aug 12 2020 at 15:27):@Risto I suspect that lld cannot do mutable globals by looking at https://github.com/llvm/llvm-project/blob/master/lld/wasm/Writer.cpp#L566
Yury Delendik (Aug 12 2020 at 15:28):/me suggests to add function/accessors and export these
Risto (Aug 13 2020 at 14:14):For now I will build the codes with emscripten, which doesn't seem to have the same issue.
I also found some posts around the web that claimed the stack pointer being at position 4 in memory as a convention or something, but I will rather try emscripten at this time than try guess if that is a valid assumption at all.
Making the getter for the stack position seems like a potential workaround, I think I found a stackoverflow post mentioning the same.
Yury Delendik (Aug 13 2020 at 14:19):"position 4" true for old emscripten, I wonder if it is still true, since new emscripten is more inline with what new clang/llvm produces
Last updated: Nov 22 2024 at 17:03 UTC