AROS hosted on aarch64 (Apple Silicon): should

x18

be reserved? I've been tracking down a class of crashes in AROS hosted on aarch64 / Apple Silicon (a macOS / Darwin host), and they all come down to the

x18

register. Background: in the AArch64 ABI,

x18

is the platform register.On Darwin (macOS, iOS) it is reserved for the operating system, and importantly it is not guaranteed to be preserved across signal handling. AROS hosted runs as an ordinary Darwin process and switches between AROS tasks using Unix signals (a timer interrupt, etc.). So if a value is sitting in

x18

when a signal fires, that value can be lost. The problem: nothing in our aarch64 toolchain tells the compiler that

x18

is off limits. The

aros

clang target does not know about the host's reservation, and we do not pass

-ffixed-x18

. So the compiler is free to use

x18

as a normal register and then have a signal-driven task switch wipe it. A concrete example from AROS's own code: the graphics HIDD's RGB-conversion / blit path crashes intermittently. At the crash,

x18

had just been computed as a valid pixel-buffer pointer (base + offset), but one instruction later, when it is dereferenced,

x18

is 0. Every other register confirms it should have been a real address. Building the affected code with

-ffixed-x18

makes the crash go away, the compiler stops using

x18

. Questions for anyone who knows the hosted-aarch64 / Darwin side: 1. Can you confirm x18 must be reserved on the Darwin-hosted aarch64 target? 2. Is any AROS code deliberately relying on`x18`(a reason not to reserve it)? 3. What is the right fix:`-ffixed-x18`across the whole aarch64-Darwin build, or should AROS's hosted task-switch / signal-return path explicitly save and restore`x18`so it stays usable?