ClangImporter: pass _WASI_EMULATED_MMAN when triple is WASI

[MaxDesiatov]

Defining _WASI_EMULATED_MMAN is required when compiling with WASI libc.

Related to SR-9307.

(cc @compnerd)

[compnerd]

Is there no intention of ever supporting mmap on WASI? If so, this is fine, otherwise, I think that we should just say that users are required to pass -Xcc -D_WASI_EMULATED_MMAN as embedding this into the driver makes that migration more difficult.

[MaxDesiatov]

It doesn't look like they're going to support it in this form without emulation:

And, some features of mmap can lead to userspace triggering signals. Accessing memory beyond the end of the file, including in the case where someone else changes the size of the file, leads to a SIGBUS on POSIX-style systems. Protection modes other than PROT_READ|PROT_WRITE can produce SIGSEGV. While some VMs are prepared to catch such signals transparently, this is a burdensome requirement for others.

Another issue is that while WASI is a synchronous I/O API today, this design may change in the future. mmap can create situations where doing a load can entail blocking I/O, which can make it harder to characterize all the places where blocking I/O may occur.

And lastly, WebAssembly linear memory doesn't support the semantics of mapping and unmapping pages. Most WebAssembly VMs would not easily be able to support freeing the memory of a page in the middle of a linear memory region, for example.

To make things easier for people porting programs that just use mmap to read and write files in a simple way, WASI libc includes a minimal userspace emulation of mmap and munmap.

I would assume that if it's ever supported, WASI would provide a different API for it. I think it would still make sense to use the current emulation API by default.

[compnerd]

Defaults here are problematic because WASI is still in flux. I really would prefer that we document the differences and make users aware of them and intentionally be explicit about the fact that there are differences from standard expectations.

[MaxDesiatov]

@compnerd since the original commit we've done plenty of changes on the WASI/Wasm side of things, for example we're requiring users to rely on import WASILibc instead of import Glibc to be explicit about the differences in libc behavior. Do you think that's explicit enough?

From that perspective the exact way mmap is implemented is an implementation detail. We could still require users to pass -Xcc -D_WASI_EMULATED_MMAN every time they build for WebAssembly. But given how WASI libc is designed, it looks like we'll have to require users targeting WASI to do it for indefinite time in the future. The vast majority of Swift users won't be concerned about this low-level implementation detail, and for those who care import WASILibc should be quite explicit. WDYT?

[MaxDesiatov]

@swift-ci please smoke test

[compnerd]

Is mman emulation the default and standard behaviour? Can the wasm VM not support it? I think that it may be better to actually require the user to spell this out in the command line of the driver invocation as -fwasm-features +emulated-mman.

[MaxDesiatov]

Is mman emulation the default and standard behaviour?

It isn't a Wasm feature, but a feature of WASI libc, so in that sense the answer is "yes". It's default and "standard" as long as we rely on WASI libc, I'm not aware of other libc implementations for Wasm. If we require our users to pass -fwasm-features +emulated-mman, they'll have to do it every time they target Wasm and WASI.

I don't think there's a way to build Swift stdlib with WASI, but without _WASI_EMULATED_MMAN.

[compnerd]

I think that my concern is that the libc itself doesn't define it. Another option to consider, if we can get it to work - add a header that is implicitly pulled in by the WASILibc that defines the macro. That should hopefully prevent he WASILibc module from being built, and it would also define the proper macros as necessary.