tweaks to enable NativeAOT-LLVM on Linux with WASI-SDK 22

[dicej]

Some of these changes are borrowed from https://github.com/dotnet/runtimelab/pull/2569.

Note that I had to manually copy pthread.h from the wasi-sdk-22/share/wasi-sysroot/include/wasm32-wasi-threads directory to the wasi-sdk-22/share/wasi-sysroot/include/wasm32-wasi directory as a workaround until https://github.com/WebAssembly/wasi-libc/issues/501 is addressed.

[dicej]

@dotnet-policy-service agree company="Fermyon Technologies"

[jkotas]

cc @dotnet/nativeaot-llvm

[dicej]

Thanks for the detailed feedback, @SingleAccretion. I'm planning to address it when I get a chance early next week.

[dicej]

The pthread situation will need to be resolved, s.t. an unmodified SDK can be used, by pulling the stubs from PalRedhawkWasm.cpp to PalRedhawkWasm.h.

I tried pursuing that, but it got ugly fast. I had to edit code under e.g. src/coreclr/gc and sprinkle new #ifdefs in a lot of places, which felt like overkill for a temporary workaround.

Then I took a step back and decided to add the following to install-wasi-sdk.ps1:

# Temporary WASI-SDK 22 workaround: Until
# https://github.com/WebAssembly/wasi-libc/issues/501 is addressed, we copy
# pthread.h from the wasm32-wasi-threads include directory to the wasm32-wasi
# include directory:

cp wasi-sdk/share/wasi-sysroot/include/wasm32-wasi-threads/pthread.h wasi-sdk/share/wasi-sysroot/include/wasm32-wasi/

If that's not acceptable, I'd vote we stick with WASI-SDK 21 for the time being, then upgrade to WASI-SDK 23, which should include a fix for https://github.com/WebAssembly/wasi-libc/issues/501.

[dicej]

FYI, this should address the missing pthread.h issue, once merged and included in a release: https://github.com/WebAssembly/wasi-libc/pull/504

[dicej]

Hm, I see cl.exe is not happy with the #pragma clang ... directives I added to suppress warnings in llvmlssa.cpp. Is there a better way to approach that?

[SingleAccretion]

Is there a better way to approach that?

It would be ideal if there was a way to propagate the warning upwards, but it looks like there isn't... Presumably, the directives can be guarded with #ifdef __clang__.

[jkotas]

Could you please resolve the conflict?

[dicej]

I've resolved the conflict and everything's green. Are we good to merge this?

[jkotas]

Thanks!