Building with THREAD_MODEL = posix

[Shillaker]

Hi all,

I can build the project just fine using both the standard LLVM 8 toolchain and prebuilt wasi-sdk, however, when I set THREAD_MODEL = posix in the Makefile I get the following error:

fatal error: error in backend: Cannot select: 0x34964f8: i32 = GlobalTLSAddress<i32* @errno> 0
In function: __reallocarray
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 8.0.1-svn369350-1~exp1~20190820121219.79 (branches/release_80)
Target: wasm32-unknown-wasi
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/reallocarray-5c3085.c
clang: note: diagnostic msg: /tmp/reallocarray-5c3085.sh
clang: note: diagnostic msg: 

********************

Before I start spending more time on it, is THREAD_MODEL = posix expected to work in the first place or is it not recommended?

I'm running on standard Ubuntu 18.04.3 LTS.

Cheers

[pchickey]

We only support THREAD_MODEL = single at this time. I don't know everything that would be required to get the posix model to work, but @sunfishcode likely wold.

[sbc100]

Building with THREAD_MODEL=posix would mean the resulting binary would only be runnable on the VM that supports the threads proposal: https://github.com/WebAssembly/threads.

Currently the only place I know that that is supported by default is in chrome or chromium-derived browsers.

Presumably as well as THREAD_MODEL=posix you would also want access to a pthreads library which wasi-sdk/wasi-libc doesn't currently provide and some low level syscalls for thread creation and destruction which are not currently part of WASI.

Having said all that, perhaps you don't actually required threads, and in this case I don't see why llvm shouldn't be able to lower away TLS accesses just like does atomics. I actually a little surprised that it doesn't.

[sunfishcode]

I believe wasm backend in LLVM 8 doesn't have TLS support; it was added in LLVM 9. And also, as others have noted, THREAD_MODEL = posix is not fully implemented in wasi-libc yet. We'd like to support it, and some parts are done, but there's more work to be done. And also, yes, to be useful outside of environments like browsers which already have threads, we'll need additional WASI APIs for threat management.

[sbc100]

@Shillaker, are you looking for threading support or would you be OK the compiler simply compiling TLS to regular global data (i.e. better support THREAD_MODEL = single)?

For the later it sounds like you could try LLVM 9. For the former, there is more work do be done.

[Shillaker]

Thanks for the quick and detailed responses. Sorry I should have been clearer before, the answer is more the latter. I'm doing some research for which I'd like to compile some legacy pthread-based code to wasm and produce a binary that makes all the "normal" thread-related syscalls. As a result I don't need a compliant VM, just something that compiles. I didn't know about the LLVM 9 TLS support so I'll have a play with that and try to include standard pthreads from musl. Thanks again for the info, very much appreciated!