The conditions to hit this are quite specific but presumably it can affect NativeAOT on win-arm64 (1). That said, to see any issue we'd need to run unwinding exactly at the very first instruction of such optimized funclet epilog (2) and that may be very rare to happen in practice. The only reason it was hit on CoreCLR in the referenced PR was due to GC stress testing that we are missing on AOT (3).

(1) On Unix we use different unwinding format and handle epilogs differently so it's not an issue there.
(2) For any other instruction in the epilog we should not be at GC safepoint, so full stack unwinding should not take place. Hijacking inside epilog is generally forbidden and we'd be past the FP/LR savepoint, so that should naturally fail.
(3) ... and likely also combination of JIT stress testing that forced specific frame type for the prolog. However, this can be reached with regular code too. For the given case we'd just need to use stackalloc in the method. It may also affect epilog of other frame types though, so I am mentioning it only for completeness.

Looks like there are no diffs (but our coverage of NativeAOT in SPMI is extremely small)

@filipnavara should it be merged then?

@filipnavara should it be merged then?

Let's wait for the GC stress on the other PR as additional verification.

(1) On Unix we use different unwinding format and handle epilogs differently so it's not an issue there.

Does it mean we can / should exclude it from Unix? 👀

Does it mean we can / should exclude it from Unix? 👀

No, it will apply to CoreCLR/Unix once we get the PSPSym PR merged too. We can optimize the prologues/epilogues separately, there will be more stuff to clean up.