AArch64 JIT backend

[bmdhacks]

Enable HashLink VM on AArch64 (Apple Silicon, ARM Linux servers, etc.) by adding a new JIT backend alongside the existing x86/x64 one.

• Rename jit.c to jit_x86.c, extract shared code into jit_common.h/jit_shared.c
• Add jit_aarch64.c/jit_aarch64_emit.c for ARM64 instruction selection and encoding
• Add jit_elf.c for GDB JIT debug interface
• Architecture-aware JIT selection in Makefile and CMakeLists.txt
• Add aarch64 support in hl.h, profile.c, hlmodule.h, module.c

[bmdhacks]

Just some background on this submission. I created this backend for some work on the PortMaster project of running classic PC games on cheap arm linux handhelds. It was developed entirely with claude code, so if you have an aversion to LLM development, this is severely tainted. It's been tested on haxe unit.hl as well as running Dead Cells on my M2 Asahi Linux machine.

It's not super fancy, the register allocation scheme is pretty basic. We do try to utilize callee and caller-saved registers when we can. Still, it runs well enough for my needs.

[tobil4sk]

Hi, this looks quite exciting! :) Just a few general comments, which will hopefully help clean things up a bit. I haven't looked at the actual jit implementation, hopefully someone else might be able to.

[ncannasse]

Interesting but a lot of changes. One question: does your implementation passes Haxe compiler unit tests? That would be a requirement before any merge.

[bmdhacks]

Interesting but a lot of changes. One question: does your implementation passes Haxe compiler unit tests? That would be a requirement before any merge.

Yes all but three related to stack trace formatting.

[tobil4sk]

There is also this place in CI that should be updated for arm64 support:

hashlink/.github/workflows/build.yml

Line 329 in e83fc71

if [[ ${{ matrix.architecture }} != arm64 ]]; then

Also wonder if jit_common.h and jit_shared.c make more sense to be named the same thing?

[Simn]

Since call stacks were mentioned and we're currently investigating a platform-specific HL problem related to that, could you try running https://github.com/HaxeFoundation/hxcoro/blob/master/callstack-tests/build-hl.hxml and let me know how that goes?

[bmdhacks]

Since call stacks were mentioned and we're currently investigating a platform-specific HL problem related to that, could you try running https://github.com/HaxeFoundation/hxcoro/blob/master/callstack-tests/build-hl.hxml and let me know how that goes?

$ hl callstack-tests/bin/test.hl
PASS asyncscope
PASS awaitcontinuation
PASS awaittask
PASS cancellation
PASS catchrethrow
PASS directthrow
PASS foobarbaz
PASS implicitlazy
PASS lazytask
PASS nestedplainthrow
PASS scopetask
PASS siblingcancellation
PASS supervisortask
PASS timeout
PASS toprecursion

Results: 15 passed, 0 failed

[Simn]

Nice! That means #892 really is a problem with the x86 jit.