AOT LLVM - Issue migrating from 8 to 9 (bad wasm file version: 0x1000d (expected 0x1))

[sardonic1]

I have a wasi-wasm project compiling a WASM successfully under the 8.x compiler, validated by wabt, and running in a Chicory runtime. E.g.

<PackageReference Include="Microsoft.DotNet.ILCompiler.LLVM" Version="8.0.0-*" />
<PackageReference Include="runtime.win-x64.Microsoft.DotNet.ILCompiler.LLVM" Version="8.0.0-*" />

However, when I try to switch to the 9.x compiler e.g.

<PackageReference Include="Microsoft.DotNet.ILCompiler.LLVM" Version="9.0.0-*" />
<PackageReference Include="runtime.$(NETCoreSdkPortableRuntimeIdentifier).Microsoft.DotNet.ILCompiler.LLVM" Version="9.0.0-*" />

A WASM is output with the WASM magic number, but a version of 0x1000d as reported by wabt wasm_validate. Is this by design? Has the 9.x compiler moved beyond and no longer supporting version 1 or is there some silent failure munging the output wasm bytes?

[SingleAccretion]

A WASM is output with the WASM magic number, but a version of 0x1000d as reported by wabt wasm_validate. Is this by design?

Yes, this is expected.

In .NET 9, we (.NET in general) have moved to depending on WASI Preview 2 (as opposed to WASI Preview 1), and producing WASM Components instead of core WASM modules. The components use a distinct binary format, which is why you see validation errors.

If you are unable to change the WASM runtime in use (to one that supports running components natively, e. g. wasmtime), I am afraid staying on .NET 8 is the only option for the time being. In the longer term, we may bring back the ability to produce core WASM modules (see WebAssembly/component-model#378), but they would still depend on WASI P2 APIs.

@dotnet/nativeaot-llvm

[pavelsavara]

In the longer term, we may bring back the ability to produce core WASM modules

I would strongly prefer not to do that, because we don't have resources to support too many build configurations and tooling.

WASI preview 1 is dead end.

[pavelsavara]

Also we now consume WASIp2 APIs directly (not via libc shims) so there is truly no way back.
wasi-libc would eventually become also just dependent on p2 or p3