Aarch64 support: What is missing?

[PhilippGackstatter]

Hello,

I've seen #576 and #565, and I'm wondering what is missing for aarch64 support? From my understanding, lucet uses cranelift to generate native code, and cranelift has support for aarch64 codegen. So I assume that's not the issue. Other issues I can guess are the x86-specific assembly in lucet-runtime/lucet-runtime-internals/src/context/context_asm.S and the missing build for an aarch64 version of the wasi-sdk.

Are those the issues that prevent lucet from getting aarch64 support, or is it more? Basically I'm just curious what would need to be done to add that support.

Thank you!

[iximeow]

As you've noticed, the x86-specific assembly is a real impediment - some of the signal handling machinery relies on knowing the OS's layout for ucontext_t, which will have a different layout on aarch64 (and vary by OS just the same). In context/mod.rs there's some poking and prodding to put arguments in place conformant to the system's calling convention - this could vary but by targeting the sysv calling convention and only supporting linux/macos/freebsd we've not needed to vary there yet. aarch64 would force that need :)

A while ago I tried adding x86-32 support on a lark and I think that would be a good template for how a new architecture would look otherwise. aarch64 wouldn't have the 64/32-bit pointer compatibility pieces though, of course.

This all said, I would highly recommend looking into Wasmtime to run programs on aarch64 systems: the current plan is to merge the two runtimes, or at least contribute Lucet's distinct features to Wasmtime (Wasmtime is already approaching a similar precompilation story with compiled code caching, for example). Unless you have a pressing need for Lucet-specific features, Wasmtime will be the better choice, with support for reference types and other future-facing WebAssembly standards implementation.

[PhilippGackstatter]

Thanks for the reply!

the current plan is to merge the two runtimes

That's really cool, looking forward to that. Then I will focus on wasmtime instead. Thanks again.