Any plan to support X86-32?

[wenzhang-dev]

currently, lucet runtime and cranelift codegen back ARM32, ARM64 and X64, but I want to know Why not choose to support x86-32? What are the considerations?

Background: Working on the lightweight multi-tenant WASM32 runtime. Lucet can do tenant isolation better if it can generate ELF32.

[cfallin]

I want to know Why not choose to support x86-32? What are the considerations?

Hi @MichealZwen -- we'd love to do so; the only real issue is time and resources. As far as I'm aware, none of the Cranelift developers has the time to prioritize x86-32 support above all of the other things that we need to work on. It would probably be several months of fulltime work (1-2 months for someone already familiar with the codebase). If you or someone else is interested in working on this, I'd be happy to provide some pointers. Thanks and sorry I can't be of more help!

[iximeow]

Lucet-wise, we'd strongly recommend moving from Lucet to Wasmtime (which these days also supports distinct compile/execute phases, and userfaultfd for memory management) - even if Cranelift did support x86-32, I think it's relatively unlikely that we'd land the necessary changes in lucet-runtime to support that. Lucet is primarily in a maintenance mode these days, and generally Wasmtime should be a viable replacement with the benefit that it's more actively up to date with work on WASM proposals, support for more architectures, and a better story for interop with various host languages.

For a sense of scale for x86-32 support in Lucet, I did a PoC of x86-32 support in Lucet a year or so ago that is still probably about right. This depended on an old x86 Cranelift backend that has since been deprecated and removed. (not a point against x86-32 support in Cranelift, the old x86-32 backend also needed some care before seeing real workloads too)

I see you mentioned ARM32 and ARM64; Lucet doesn't support ARM at all today, and would need more substantial changes for those architectures. Another point in favor of Wasmtime is that it already supports ARM32/ARM64. It doesn't make so much sense to repeat that work when Wasmtime does a great job with them already. While the code generator both runtimes use is shared, Lucet does not have support for architecture-specific details in running ARM code, meaning those architectures would also need some work like with the x86-32 PR I linked aboove.

As Chris noted, for Cranelift to support x86-32 in either Lucet or Wasmtime it'll need work either way, and I know I'd be super excited to see proper support for x86-32 in Cranelift, so please don't let me dissuade you if you're interested!

[cfallin]

Ah, yes, I have just realized that this issue is on the Lucet repo and not Cranelift (my mistake, unified notifications inbox...); please interpret my comments above in the context of Cranelift generally :-)

[wenzhang-dev]

I'd love to, but maybe I'm not familiar with codebase.
I'd like to consult you. How to do lightweight memory isolation in WASmTime or Lucet Runtime?
So far I see userFaultfd being used, but it seems like it can only notify the user layer of page faults in registered address spaces? This approach will not work if illegal access to a physical page is already mapped.