Fix Linux ARM64 build by ivankra · Pull Request #7051 · chakra-core/ChakraCore

ivankra · 2025-12-23T22:04:04Z

It builds with clang 18-22 on recent Debian/Ubuntu, both with and without ICU, passes tests and benchmarks.

Key issues:

Different ARM64 vararg calling convention between macOS (DarwinPCS) and Linux (AAPCS64).

Fixed CALL_ENTRYPOINT_NOASSERT and DECLARE_ARGS_VARARRAY using va_list.__stack from the official ABI - robust and compiler-independent.

However, there is also JavascriptStackWalker.cpp which depends on the exact stack layout and magic constants, especially ArgOffsetFromFramePtr, this part is more fragile.
char is unsigned in Linux ARM64 ABI unlike macOS/Win, breaking int8 code. Make sure __int8 (=char) is always prefixed with signed/unsigned.
arm64/*.S files use Microsoft-style ; comments, unsupported by GNU assembler. These were already converted in amd64/*.S files to //, but I propose a simpler fix to just strip them on the fly during the build with sed.
Missing _GetNativeSigSimdContext based on https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/src/thread/context.cpp#L927
Cpsr register is PState on Linux
wchar_t/char16_t mismatches when building with ICU - caused by libstdc++ on Debian undefining macros like wcslen. Solved by including problematic system headers early in pal.h.
Minor compile errors and bugs fixed along the way: MAX_INT is not an exact float, UNumberFormatFields cast, strict aliasing bug in LuHiDbl/LuLoDbl, TZ=US/Pacific doesn't always exist, __reserved in sal.h conflicts with signal.h.

Note: binary with JIT crashes - this must be built with ./build.sh --no-jit. cmake already prints a warning that ARM64 JIT is only supported on Windows.

Tested as follows:

cat >Dockerfile <<EOF
ARG BASE=ubuntu:24.04
FROM $BASE
RUN export DEBIAN_FRONTEND=noninteractive && apt-get update -y && apt-get install -y --no-install-recommends build-essential ca-certificates clang cmake git libicu-dev llvm ninja-build python3 tzdata
EOF

BASE=ubuntu:24.04; podman build --build-arg BASE=$BASE -t chakra-$BASE . && podman run --rm -it -v $PWD:$PWD -w $PWD chakra-$BASE /bin/bash -c "rm -rf out; ./build.sh --ninja --no-jit && ninja -C out/* check"

For these combinations: ubuntu:22.04 (clang 14), ubuntu:24.04 (clang 18), ubuntu:26.04 (clang 21), debian:stable (clang 19), debian:sid (clang 21), and three build commands: ./build.sh --ninja --no-jit, ./build.sh --ninja --no-jit --debug, ./build.sh --ninja --no-jit -t.

ubuntu:22.04 with ./build.sh --ninja --no-jit -t crashes in JavascriptStackWalker, but everything else passes.

Benchmarking on Octane test suite is on par with JIT-less SpiderMonkey (on Mac M4):

Benchmark	chakracore_jitless	sm_jitless	v8_jitless	quickjs
Richards	566.27	508.91	2050.18	1748.91
DeltaBlue	509.45	524.45	2224.36	1594.91
Crypto	895.73	809.82	1902.64	2277.55
RayTrace	1360.36	1717.91	7105	3132.91
EarleyBoyer	2055.25	2389	11803.75	3840
RegExp	2533.75	1012.25	5484.75	859.50
Splay	4166	3533.25	12368.50	4153.50
NavierStokes	1240.50	1484.75	3473.25	4385.25
gmean	1324.31	1213.76	4510.95	2425.15

Fixes #7050

Key issues during port: * Different ARM64 vararg calling convention between macOS (DarwinPCS) and Linux (AAPCS64). Fixed CALL_ENTRYPOINT_NOASSERT and DECLARE_ARGS_VARARRAY using va_list.__stack from the official ABI - robust and compiler-independent. However, there is also JavascriptStackWalker.cpp which depends on the exact stack layout and magic constants, especially ArgOffsetFromFramePtr, this part is more fragile. * char is unsigned in Linux ARM64 ABI unlike macOS/Win, breaking int8 code. Make sure __int8 (=char) is always prefixed with signed/unsigned. * arm64/*.S files use Microsoft-style ; comments, unsupported by GNU assembler. These were already converted in amd64/*.S files to //, but I propose a simpler fix to just strip them on the fly during the build with sed. * Missing _GetNativeSigSimdContext based on https://github.com/dotnet/runtime/blob/main/src/coreclr/pal/src/thread/context.cpp#L927 * Cpsr register is PState on Linux * wchar_t/char16_t mismatches when building with ICU. For now solved with #define wcslen PAL_wcslen etc in ChakraICU.h. It builds at least, though some Intl tests are failing. Note: binary with JIT crashes - this must be built with ./build.sh --no-jit. cmake already prints a warning that ARM64 JIT is only supported on Windows.

rhuanjl

Thank you for your work on this; it's certainly good to support another platform.

I've put a few initial comments above though I'm going to want to another slightly more detailed review.

Are you able to sign our Contributor agreement? https://github.com/chakra-core/ChakraCore/blob/master/ContributionAgreement.md

lib/Runtime/PlatformAgnostic/ChakraICU.h

CMakeLists.txt

rhuanjl · 2025-12-23T23:45:49Z

lib/Runtime/Language/Arguments.h

+// Linux ARM64 uses AAPCS64: first 8 args in x0-x7, rest via stack.
+// Fill x2-x7 with nulls here to force the expected stack layout:
+// [RetAddr] [function] [callInfo] [args...]
+#define CALL_ENTRYPOINT_NOASSERT(entryPoint, function, callInfo, ...) \


I'd expect this to break the JavascriptStackWalker, I saw you said it was "fragile", what's the status?

The single hard-coded constant ArgOffsetFromFramePtr that JavascriptStackWalker relies on feels rather fragile to me. For now, I set ArgOffsetFromFramePtr=4 - I see 8 extra bytes of what seems like padding or saved registers. But I'd expect it to break with different compilers and optimization flags by analogy with my experience with DECLARE_ARGS_VARARRAY - at first (before I found va_list.__stack) I was trying to fixing it by trying different offsets in _get_va(), but it just kept breaking between optimized and debug builds.

JavascriptStackWalker in JIT-less builds so far works for me with clang 19, 20, and 22, both optimized and debug builds. Perhaps because it only needs to deal with a few specific call sites in this mode. When JIT is enabled it is crashing, but because JIT wasn't supported on macOS, I didn't investigate these crashes further.

The JIT crash is not remarkable, the ARM JIT contains significant windows specific logic that needs re-writing for Linux/macOS including the way function entry and exit is setup and the managing of the stack layout.

For calling JS functions in the interpreter we go via arm64_CallFunction to set the stack exactly the way we need for the stack walker and argument handling to work: https://github.com/chakra-core/ChakraCore/blob/master/lib/Runtime/Library/arm64/arm64_CallFunction.S

test/Number/toString.js

ivankra · 2025-12-24T02:07:24Z

Are you able to sign our Contributor agreement? https://github.com/chakra-core/ChakraCore/blob/master/ContributionAgreement.md

Yes, added my name there.

Include system headers that may cause to PAL_* macros to get undefined early in pal.h.

Seemingly only needed for macOS. Linker complains about references to it under some configurations.

US/Pacific is a legacy alias, unavailable in the standard installation of Debian 13, which moved it to tzdata-legacy.

ivankra · 2025-12-26T14:53:00Z

I fixed the remaining errors that I encountered.

For the unicode errors: they were ultimately caused by Debian's libstdc++ undefining wcslen etc macros. I changed the fix to include the problematic system headers early in pal.h: ivankra@6bba7ee

Tested commit c8cce2106209880d1c8b8d9f3f805c9c01eaeb37 in three build modes: ./build.sh --ninja --no-jit, ./build.sh --ninja --no-jit --debug, ./build.sh --ninja --no-jit -t with command like this:

cat >Dockerfile <<EOF
ARG BASE=ubuntu:24.04
FROM $BASE
RUN export DEBIAN_FRONTEND=noninteractive && apt-get update -y && apt-get install -y --no-install-recommends build-essential ca-certificates clang cmake git libicu-dev llvm ninja-build python3 tzdata
EOF

BASE=ubuntu:24.04; podman build --build-arg BASE=$BASE -t chakra-$BASE . && podman run --rm -it -v $PWD:$PWD -w $PWD chakra-$BASE /bin/bash -c "rm -rf out; ./build.sh --ninja --no-jit && ninja -C out/* check"

On these userlands: ubuntu:22.04 (clang 14), ubuntu:24.04 (clang 18), ubuntu:26.04 (clang 21), debian:stable (clang 19), debian:sid (clang 21).

Everything builds and passes all disable_jit tests, except for a single combination: ubuntu:22.04 with ./build.sh --ninja --no-jit -t crashes in JavascriptStackWalker. Looks like stack layout mismatch, and more profound than a merely wrong ArgOffsetFromFramePtr. I'd suggest to ignore it since it uses a rather old clang, and on newer systems everything passes.

parseInt("4294967296") returned 1 due to strict aliasing bug at BigUInt.cpp:529. Fix LuHiDbl/LuLoDbl to prevent similar issues caused by them: access uint32 via a union, and __may_alias__ annotation for clang.

rhuanjl · 2025-12-27T10:01:36Z

@ppenzin any thoughts?

I'd like to do one more read through later before merge to check for any oddities I've missed.

But unless I notice anything else, I think we should bring this in and then maybe one of us could open a new PR to add CI for it (and remove the build time warning assuming we get CI to pass).

rhuanjl · 2025-12-27T10:08:09Z

Everything builds and passes all disable_jit tests, except for a single combination: ubuntu:22.04 with ./build.sh --ninja --no-jit -t crashes in JavascriptStackWalker. Looks like stack layout mismatch, and more profound than a merely wrong ArgOffsetFromFramePtr. I'd suggest to ignore it since it uses a rather old clang, and on newer systems everything passes.

I'm always a bit nervous when there's an error we can't understand - if the stack walker is not working it's likely an incompatibility between the Call entry point handlers in Arguments.h and arm64_CallFunction; but it's odd that it would work on the newer compilers but not Clang14.

ppenzin · 2025-12-28T02:48:33Z

Ubuntu 22.04 is going to go into security-only mode relatively soon, that can make reproducing this a bit difficult in the future, that's why I'm not sure how important it would be to fix. @ivankra how much of test suite is failing?

This PR fixes Clang 21 miscompilation that we recently found. Overall it looks reasonable, but I will take another look at it.

ivankra · 2025-12-29T08:09:17Z

Much of the test suite fails in that particular combination:

$ export BASE=ubuntu:22.04; podman build --build-arg BASE=$BASE -t chakra-$BASE . && podman run --rm -it -v $PWD:$PWD -w $PWD chakra-$BASE /bin/bash -c "rm -rf out; ./build.sh --ninja --no-jit -t && ninja -C out/* check" 
...
############ Results for disable_jit tests ###########
...
# Total: passed 1120, failed 835

So, in a way, it would be be easy for a user to notice something is wrong with a built binary.

rhuanjl

If/when we remove the existing CMake warning we can put in a Clang version check and warn for versions less than 15 or something.

Waiting on @ppenzin's review before we merge.

rhuanjl · 2026-01-01T09:27:12Z

pal/src/thread/context.cpp

+static inline fpsimd_context* _GetNativeSigSimdContext(unsigned char* data, size_t size)
+{
+    size_t pos = 0;
+    while (pos < size)
+    {
+        _aarch64_ctx* ctx = reinterpret_cast<_aarch64_ctx*>(&data[pos]);
+        if (pos + sizeof(_aarch64_ctx) > size)
+        {
+            break;
+        }


I had another look at this, and I was wondering why it's so different to the function it's based on in dotnet, does the dotnet version require something we don't have or did it contain a performance trap?

I rewrote it from scratch. Dotnet's version is more general returning fpsimd_context and sve_context, but Chakra only needs fpsimd_context.

ppenzin

LGTM

ppenzin · 2026-01-07T23:36:44Z

@rhuanjl, not sure I understand your comment about CMake warning, aside from that I don't have any issues with merging this PR.

ppenzin requested review from ppenzin and rhuanjl December 23, 2025 23:06

rhuanjl reviewed Dec 23, 2025

View reviewed changes

CLA, copyrights, ARM64 linux warning, reenable toString.js on macOS.

830ee4b

ivankra force-pushed the linux-arm64 branch from 272fdbf to 830ee4b Compare December 24, 2025 02:31

ivankra added 4 commits December 26, 2025 22:13

Alternative fix for unicode errors

6bba7ee

Include system headers that may cause to PAL_* macros to get undefined early in pal.h.

Fix PAL_DispatchException linker error

2b633a3

Seemingly only needed for macOS. Linker complains about references to it under some configurations.

Fix UnsetField compile error under newer clang

1cf0797

Fix DateTimeFormat.js error: TZ=US/Pacific -> America/Los_Angeles

5dcba40

US/Pacific is a legacy alias, unavailable in the standard installation of Debian 13, which moved it to tzdata-legacy.

Fix ParseInt1.js error

0c37dae

parseInt("4294967296") returned 1 due to strict aliasing bug at BigUInt.cpp:529. Fix LuHiDbl/LuLoDbl to prevent similar issues caused by them: access uint32 via a union, and __may_alias__ annotation for clang.

ivankra force-pushed the linux-arm64 branch from c8cce21 to 0c37dae Compare December 26, 2025 15:00

rhuanjl approved these changes Dec 29, 2025

View reviewed changes

rhuanjl reviewed Jan 1, 2026

View reviewed changes

ppenzin approved these changes Jan 7, 2026

View reviewed changes

Merge branch 'master' into linux-arm64

b2240be

rhuanjl merged commit 792ee76 into chakra-core:master Jan 8, 2026
21 of 24 checks passed

Conversation

ivankra commented Dec 23, 2025 • edited by ppenzin Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhuanjl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rhuanjl Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

ivankra Dec 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rhuanjl Dec 27, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ivankra commented Dec 24, 2025

Uh oh!

ivankra commented Dec 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhuanjl commented Dec 27, 2025

Uh oh!

rhuanjl commented Dec 27, 2025

Uh oh!

ppenzin commented Dec 28, 2025

Uh oh!

ivankra commented Dec 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rhuanjl left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rhuanjl Jan 1, 2026

Choose a reason for hiding this comment

Uh oh!

ivankra Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

ppenzin left a comment

Choose a reason for hiding this comment

Uh oh!

ppenzin commented Jan 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

ivankra commented Dec 23, 2025 •

edited by ppenzin

Loading

ivankra Dec 24, 2025 •

edited

Loading

ivankra commented Dec 26, 2025 •

edited

Loading

ivankra commented Dec 29, 2025 •

edited

Loading

rhuanjl left a comment •

edited

Loading