Hello here. Just found something interesting: Wasm modules being translated to C. Source: https://github.com/turbolent/w2c2

Unusual considering that developers normally do it the other way round.

I guess it could be useful as a step of AOT compilation. C can be compiled to any target and has many mature optimising compilers.

Firefox does this as a sandboxing technique: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/

Rather than hoisting the code into a separate process, we instead compile it into WebAssembly and then compile that WebAssembly into native code. This doesn’t result in us shipping any .wasm files in Firefox, since the WebAssembly step is only an intermediate representation in our build process.

We accomplished this with wasm2c, which performs a straightforward translation of WebAssembly into equivalent C code, which we can then feed back into Clang along with the rest of the Firefox source code. This approach is very simple, and automatically enables a number of important features that we support for regular Firefox code: profile-guided optimization, inlining across sandbox boundaries, crash reporting, debugger support, source-code indexing, and likely other things that we have yet to appreciate.

Essentially the C compiler is being used apply optimisations, provide debugging and other tool support, before the code is converted to WASM again. One wonders why the optimisations aren't being applied at the WASM level.

I though C from tools like w2c2 is meant to be compiled to Native code. Converting code to Wasm multiple times in the build chain could accumulate the Wasm overhead. Do you know anyone doing this?

before the code is converted to WASM again

No, it’s not. It’s compiled to native code and shipped as part of Firefox. This is not about WASM support in Firefox, this is about Firefox team using WASM internally as an intermediate step to achieve sandboxing for different parts of the Firefox itself (like parsers and such), which interact with user data.

Very odd considering that Firefox on Linux can be installed as a FlatPak or Snap package, which has a built-in sandbox (an isolated container). Other OS's may have a similar self contained packaging format.

I think it is more about sandboxing subsystems within Firefox so that bug in one subsystem would not cause vulnerability in the other.