WIP: wasm ci

[skoppe]

The druntime/phobos submodules are pointing to my cloned repos. Will replace when they are merged upstream.

I approached the wasm ci the same as android. For a minute I considered packaging the wasm libs as part of a normal build, but since this goes against the current setup I didn't do that.

According to the Cross-linking executables and shared libraries section in Cross-compiling_with_LDC end-users that want to compile to wasm will need to download the wasm artifact, manually place the libs somewhere and change the ldc2.conf file. I wonder if there is an easier way to do this. (maybe a ldc2 setup wasm32-wasi?)

In the wasm artifact there are only sources and the libs, there is no ldc since I haven't gone through the trouble of building ldc for wasm (I might, I know someone did it for clang).

To use:

Following the instructions at cross-linking above, create a hello-world app.d and dub build --build-mode=allAtOnce --arch=wasm32-wasi.

--build-mode=allAtOnce is required otherwise I get undefined symbol: _Dmodule_ref.

BetterC build are still possible, and don't use the runtime.

[kinke]

Thanks, looking good.

[kinke]

BetterC build are still possible, and don't use the runtime.

Yes, but WASI libc won't be linked automatically, as -betterC discards all -defaultlib. The compiler has a hardcoded list of C libs to be linked, but that's not ideal either. Maybe we should add another switch for these C libs; baremetal guys would then simply clear both to have full control over the linked libs.

[kinke]

I wonder if there is an easier way to do this. (maybe a ldc2 setup wasm32-wasi?)

See https://github.com/adamdruppe/d_android/blob/master/android-setup.d. It's currently limited to Android, but could/should be generalized (for all prebuilt GitHub packages) and bundled with LDC, as tiny convenience tool like ldc-build-runtime.

[kinke]

--build-mode=allAtOnce is required otherwise I get undefined symbol: _Dmodule_ref

The compiler could be adapted to use a different method of bundling the ModuleInfo pointers of linked modules for druntime use (see gen/modules.cpp); the legacy linked list isn't cheap/elegant (one 'global ctor' function call for each module to build the linked list). Not sure what's suitable for wasm; normally, the pointers are emitted into a custom .minfo section, and druntime parses the image headers to obtain the memory range [edit: or relies on magic linker symbols bracketing a section].

[kinke]

Looks like LLD supports the magic __start/stop linker symbols for wasm too: https://github.com/llvm/llvm-project/blob/e6d9b2cb92dd8ad544f43dc97e82fa98e07e977c/lld/test/wasm/startstop.ll#L11-L12

[kinke]

=> #3348

[skoppe]

See https://github.com/adamdruppe/d_android/blob/master/android-setup.d. It's currently limited to Android, but could/should be generalized (for all prebuilt GitHub packages) and bundled with LDC, as tiny convenience tool like ldc-build-runtime.

I will contact adam about this and generalize it to work for all prebuild packages.

[skoppe]

BetterC build are still possible, and don't use the runtime.

Yes, but WASI libc won't be linked automatically, as -betterC discards all -defaultlib. The compiler has a hardcoded list of C libs to be linked, but that's not ideal either. Maybe we should add another switch for these C libs; baremetal guys would then simply clear both to have full control over the linked libs.

Ah yes of course, that is also an option. Although I don't see anyone using wasm + wasi + betterC right now. The easiest solution for them is to link the wasi libc themselves, or just call wasi directly, as they still have access to the druntime wasi bindings.

[kinke]

I will contact adam about this and generalize it to work for all prebuild packages.

Awesome, thx. The tool was sketched out in https://forum.dlang.org/post/[email protected].

[kinke]

LLVM 10 introduced TLS support for wasm: https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html#changes-to-the-webassembly-target

Should we undo the no-TLS hack accordingly?

[skoppe]

I prefer to get a working version of druntime out first. Unless I really run into no-tls issues.

Corona has cut into my free time a bit, but a couple days ago I managed to compile almost all phobos' unittests (the ones that make sense).

Also, I like to tackle threads and tls in one go, but since threads in wasm are a bit different than normal threads, I prefer to avoid the additional complexity at this point.

[skoppe]

I finally found some time to get all unittests passing (those that make sense). Will try to get them running in the CI as well. Then update to latest druntime/phobos and to latest WASI sdk.

[MrcSnm]

Is there any update on that? Following every instruction I wasn't still able to compile for wasm. Even tried following the same instructions for wasi-12 but I get undefined FILE and time_t when compiling core/stdc/stdio

[skoppe]

Is there any update on that? Following every instruction I wasn't still able to compile for wasm. Even tried following the same instructions for wasi-12 but I get undefined FILE and time_t when compiling core/stdc/stdio

I haven't compiled for a long time, but with the right versions you should be able to. Several people have.

At some point I will be getting back to this. Maybe if I get a week or two off from work (and family 😛 )