wasip3: Calls to `__wasm_get_stack_pointer` should directly invoke the imported `context.get` intrinsic

[alexcrichton]

I'm extracting out an issue for my comment at #799 (comment). Currently the __wasm_get_stack_pointer function is a non-inlinable inline assembly function that, at the wasm level, calls the context.get intrinsic which is imported. This indirection is not boiled away by runtimes like Wasmtime by default, and I think it's something that we should strive to fix at the toolchain level. This may require changes in wasm-ld, or may require changes here, I'm not entirely sure.

[alexcrichton]

@sbc100 I was wondering if I could get your thoughts on this and how best to solve this. Possible solutions I'm thinking of range from "do nothing" to new wasm-ld flags/configuration to new tooling conventions. The basic problem right now is that with wasip3 and --cooperative-threading the stack pointer is found via call $__wasm_get_stack_pointer and the goal is to hook this up directly to an import in the wasm module, but today that's not quite possible.

Today the workaround looks like this where __wasm_get_stack_pointer is a defined symbol which calls the desired symbol. The desired symbol today has both the wasm-level module name and field name configured to match the current wasm-component-ld conventions. I'd ideally like to be able to do something like:

    .functype __wasm_get_stack_pointer () -> (i32)
    .import_module __wasm_get_stack_pointer, "$root"
    .import_name __wasm_get_stack_pointer, "[context-get-0]"

but this fails with:

wasm-ld: error: import module mismatch for symbol: __wasm_set_stack_pointer
>>> defined as env in /home/alex/code/wasi-libc/build/p3t/sysroot/lib/wasm32-wasip3/crt1-command.o
>>> defined as $root in libc-static.a(__libcall_thread_context.S.obj)

One possible solution is to use --wrap:

    .globl __wrap___wasm_get_stack_pointer
    .functype __wrap___wasm_get_stack_pointer () -> (i32)
    .import_module __wrap___wasm_get_stack_pointer, "$root"
    .import_name __wrap___wasm_get_stack_pointer, "[context-get-0]"

when combined with -Wl,--wrap=__wasm_get_stack_pointer produces the executable as-desired. One wrinkle here is that there's a segfault when producing a shared library and I'm not entirely sure what that's about. This also feels like a bit of an abuse of --wrap as well, hence my thinking of pursuing more options.

Another possible option would be a new flag to wasm-ld along the lines of --import=<symbol>=<module>,<name> or something like that. Personally I'm not a huge fan of wasm-ld-flag solutions because we'll also be required to pass them around, but it's a possibility.

Another possible option would be to add Clang flags/options to configure the import module and import name of this symbol when it's emitted in the wasm object itself. For example on WASIp3 targets it could default to something different than on other targets.

And, finally, the last possible option I can think of is to leave Clang as-is and update the component transform to recognize env and __wasm_get_stack_pointer to get hooked up correctly.

Do you have thoughts/opinions on how best we might go about this? I've hoped to try other alternatives like symbol aliases but I unfortunately wasn't able to get them working either.

[TartanLlama]

I think this might be the path of least resistance:

leave Clang as-is and update the component transform to recognize env and __wasm_get_stack_pointer to get hooked up correctly.

Can view it as something of a linker inlining operation to avoid the indirection