SME ABI for sigsetjmp/siglongjmp

[pmsjt]

It is possible that this question is better discussed in other forums, such as the Linux ABI, but when these APIs are involved, the lines between what POSIX and Exception Handling begin to blur.

POSIX allows software to exit a signal handler by calling siglongjmp, bypassing the more common signal return [1].

When a signal is delivered, and execution is transferred to its handler, it is expected that ZA will be in the off state and all SME state to be persisted in the signal frame [2]. Signals can be delivered when SME is in any state, including the dormant state. Delivering a Signal will not commit the lazy state.

Since siglongjmp will truncate and discard the signal frame, it is not possible to delay the committal of lazy state to siglongjmp instead of making it upfront on sigsetjmp without risking the loss of ZA state, as it is recommended for setjmp/longjmp [3].

Should Arm extend its recommended ABI to include subjects like POSIX Signals and even Windows Structured Exception Handling, beyond basic setjmp/longjmp and C++ EH?

[1]
https://www.man7.org/linux/man-pages/man3/siglongjmp.3p.html

[2]
https://github.com/torvalds/linux/blob/master/Documentation/arch/arm64/sme.rst#5--signal-handling

[3]
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#setjmp-and-longjmp

[fweimer-rh]

Note that use of siglongjmp in signal handlers is more restricted than what the manual page suggests. You cannot use it to jump out of signals that interrupted arbitrary code. Having special rules for interrupting SME code regions is possible.

[smithp35]

As a general rule the sysvabi64 would be the most appropriate place to document POSIX specific interactions with the Arm 64-bit Architecture https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst

The Arm ABI normally doesn't comment on platforms, like Windows, that have their own ABI defined by the platform holder so we likely wouldn't cover structured exception handling.

I can't comment fully on the specifics of siglongjmp and SME at the moment.

[pmsjt]

In cases where the OSs ABI merely extends the Arm prescribed ABI, this distinction may not be as black and white. A parallel could be made to how new languages extend what Arm defines for C/C++.

It is not lost in me that accounting to all possible language and OS extensions presents a very clear scalability problem.

[smithp35]

I've raised an issue #291 so this doesn't get forgot about. If there are any comments please use this. I'll close this discussion for now.