WIP: Improve Emscripten support

[kinke]

Based on WASI.

[kinke]

@QuantumSegfault: This seems like a viable approach - basing Emscripten on your WASI work, after reading https://v8.dev/blog/emscripten-standalone-wasm and noting that they apparently try to use WASI APIs as much as possible, even in non-standalone-wasm mode.

To get the druntime test runners to link, I only had to avoid a single undefined _CLOCK_MONOTONIC symbol. And a single module fails its unittests (core.sync.event): https://github.com/ldc-developers/ldc/actions/runs/31392028311/job/93465932716?pr=5259

[QuantumSegfault]

I'm not sure this makes sense to do like this.

Emscripten use a more vanilla Musl, without all of the differences to the headers WASI-libc made. They opted to stub out functions, rather than remove them, and otherwise use the unmodified types, constants, etc. (other than where architecture specific differences are concerned). A lot of the CRuntime_WASI blocks, particularly in Phobos, may be unnecessary.

WASI is also iffy, as that's an internal implementation detail. Emscripten also provides fuller emulation of things like threads, that we disable tests for on WASI. Also they provide their own filesystem, which isn't subject to all the quirks of WASI (e.g. the inability to have absolute symlinks; though that's largely a Wasmtime limitation).

[kinke]

Yeah the importc_compare test shows a number of incompatible declarations, seemingly matching your points. - I'll pursue this a bit further, trying to get it more or less green (edit: i.e., the druntime/Phobos parts tested for WASI too). Then different avenues (e.g., based on CRuntime_Musl alone instead of WASI, WASIp1 and CRuntime_WASI) can be explored as well.

I'd hope that Emscripten would eventually be based on wasi-libc...

[kinke]

Okay, this is now based on CRuntime_Musl with a few Emscripten special-cases (instead of CRuntime_WASI earlier), but still uses WASI[p1] too (mainly to inherit the disabled parts and unitests). importc_compare is truly green; druntime still fails for a single core.sync.event unittest (depending on pthread_cond_timedwait), and Phobos just fails 2 std.datetime modules unittests, apparently just because I haven't found a way to make the node process use the /usr/share/zoneinfo host timezone files.

I'm okay with depending/building on predefined WASI, at least for the time being; supporting the few potential Posix API parts being stubbed/emulated on Emscripten and not available for WASI are IMO not of big interest. What's of interest to me is that Emscripten support is at a similar level to wasi-libc, so that wasm users can target both platforms with little to no hassle.

[QuantumSegfault]

I'm okay with depending/building on predefined WASI, at least for the time being; supporting the few potential Posix API parts being stubbed/emulated on Emscripten and not available for WASI are IMO not of big interest. What's of interest to me is that Emscripten support is at a similar level to wasi-libc, so that wasm users can target both platforms with little to no hassle.

Threading is a notable difference. Emscripten actually DOES support threading (over web workers; with some caveats).

https://emscripten.org/docs/porting/pthreads.html

Signals still not, other than for pthread_kill

Though I wouldn't mind holding off on the threading discussion until I figure out WASIp3 (with wasi-sdk 34 and LLVM 23 coming up; which will support cooperative threading [like Emscripten]; no preemptive threading yet though).

---

Other than that I think the rest of the WASI route-arounds should be fine, if not always necessary.

[kinke]

Though I wouldn't mind holding off on the threading discussion until I figure out WASIp3

Yeah that sounds good to me. [And note that I've just started with WASIp1, no idea if WASIp2 might be a better match for Emscripten.] - In the long run, if Emscripten is to survive, I can definitely imagine it being based on wasi-libc and its Posix emulation layer in the future. So the distinction might go away, and duplicating all current Emscripten divergences potentially not worth the effort.

The compiler has a special case wrt. TLS globals for wasm in general IIRC, emitting them as thread-global; so the compiler will probably have to be adapted for wasm threading too.

[QuantumSegfault]

Yeah that sounds good to me. [And note that I've just started with WASIp1, no idea if WASIp2 might be a better match for Emscripten.]

I'm fairly certain that WASIp1 is the only valid option for Emscripten.

They provide a subset of WASIp1 for the web (but not p2+ AFAICT)

https://github.com/emscripten-core/emscripten/blob/main/src/lib/libwasi.js

The compiler has a special case wrt. TLS globals for wasm in general IIRC, emitting them as thread-global; so the compiler will probably have to be adapted for wasm threading too.

Good to know.

[QuantumSegfault]

These errno are correct, but Emscripten provides additional ones:

https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/musl/arch/emscripten/bits/errno.h

[kinke]

Yeah here I was lazy and didn't want to duplicate the existing CRuntime_WASI block, after seeing that the Emscripten headers forward the WASI codes. [And I don't really care about the extra ones; if people relied on them, their code wouldn't work with WASI.]

At least a comment wrt. Emscripten would be good though; there's some polishing left to do, hence the draft state and WIP title. :)

[QuantumSegfault]

Yeah. Just the one thing that stuck out as probably somehow wrong, so I checked.

I'll wait for it to be undrafted before reviewing the changes more thoroughly.

[kinke]

This is e.g. also still to polish, causing the Alpine CI job failures (no integrated LLD, but external wasm-ld).

This all dates back to the very early wasm support, like the wasm-defaults .conf file - we used to only support bare-metal wasm, so no druntime and Phobos to link, and no need for a C compiler as linker driver, since there wasn't a wasm libc support either. So we used to invoke wasm-ld (unless we have an integrated LLD) with the ld CLI interface, for all (non-WASI) wasm targets.

We can keep this behavior for backwards-compatibility, but then only when targeting an unknown/none OS. We already do that in 55-target-wasm-naked.conf nowadays, via the -link-internally (=> use integrated lld with wasm-ld CLI interface) - but only if LLD integration was enabled at build-time.

So the compiler special case here would only be needed without LLD integration. Not sure that's worth the trouble, incl. the link_WebAssembly lit complication (looking for an external wasm-ld), which I haven't gotten rid of yet.