provide __stack_high and __stack_low globals when linking

[dicej]

Beginning with WASI-SDK 28, libc.so requires these globals to be provided by the main module, presumably due to these
changes.

[alexcrichton]

Since we're in control of the stack allocation, is it possible to use the actual extents rather than 0? Also, do you know if this is an LLD thing where LLD provides these symbols? And/or do you know if it's a bug that wasi-libc requires these symbols?

[dicej]

Since we're in control of the stack allocation, is it possible to use the actual extents rather than 0? Also, do you know if this is an LLD thing where LLD provides these symbols? And/or do you know if it's a bug that wasi-libc requires these symbols?

I confess I don't know how all this fits together, but it appears to be related to how wasi-libc initializes the pthread_t for the current thread, specifically its stack and stack_size fields, which can be retrieved using pthread_getattr_np. See e.g. https://github.com/WebAssembly/wasi-libc/blob/abe7b089c1d3d9db351c8a4f4378b3871c0eae20/libc-top-half/musl/src/env/__init_tls.c and https://github.com/WebAssembly/wasi-libc/blob/abe7b089c1d3d9db351c8a4f4378b3871c0eae20/libc-top-half/musl/src/thread/pthread_getattr_np.c.

This comment indicates that wasm-ld is expected to provide them, at least for non-PIC code. I guess since, as you point out, the "dynamic linker" is responsible for allocating the stack, in the case of libc.so, it makes sense that it would not be wasm-ld's job for PIC code. In that case, you're right that we should fill in the correct values rather than zero here.

[dicej]

I just pushed an update to set __stack_high to the allocation size. __stack_low remains zero since that's really where the stack ends.

[alexcrichton]

I'm having a tough time shaking a feeling though that something's not right here. For example:

extern char __stack_high;
int foo() { return (int) &__stack_high; }

compiles with:

$ ../wasi-sdk-28.0-x86_64-linux/bin/wasm32-wasip2-clang -fPIC foo.c -shared -Wl,--export=foo && wasm-tools print foo.wasm -h
wasm-ld: warning: creating shared libraries, with -shared, is not yet stable
wasm-ld: error: /tmp/foo-cf3471.o: undefined symbol: __stack_high
error: failed to invoke LLD: exit status: 1
wasm32-wasip2-clang: error: linker command failed with exit code 1 (use -v to see invocation)

So I'm not sure what's supposed to happen here. I don't know if this is a bug in wasm-ld, a bug in wasi-libc for thinking these symbols should exist in dynamic libraries, or a bug here for wasm-tools as the symbols should be provided.

@sbc100 would you perhaps know an answer to this question? Is it expected that wasm shared-everything-dynamic-libraries (e.g. compiled with -shared) are allowed to import __stack_{high,low} symbols? Should this linker invocation above work instead of generating an error?

[sbc100]

There is an open PR against wasm-ld to allow such linker-defined symbols to be undefined in shared libraries:
llvm/llvm-project#153537

I believe in emscripten we always build our shared libraries with --unresolved-symbols=import-dynamic which will turn symbols like this into imports (and should work if you need a temporary work around)

[alexcrichton]

Ok thanks for confirmation! In that case this looks good to me