# [Patch] aarch64-win64: no SEH unwind code for stack frames of a page or more `g_stackpointer_alloc` (`compiler/aarch64/cgcpu.pas:1847`) has two paths. Below `winstackpagesize` (4096) it emits the `sub` and then `cai_seh_directive.create_offset(ash_stackalloc,localsize)`. At or above it, the Windows stack probing path emits the `sub` and the probe stores but no SEH directive at all, in either of its two sub-branches. The allocation is therefore missing from the `.xdata`, and every unwind code that follows it is applied at an `sp` that is short by the whole frame. ## Effect 1: unwinding restores the wrong non-volatile registers The programs named below are in `fpc-seh-repro.zip`, attached here and to #41870; `README.txt` in it says what each one shows and how to build them. They need `-O2`. `convert_unwinddata` stores the codes in reverse prolog order, and `g_proc_entry` saves x19-x28 and d8-d15 after establishing x29 but before allocating locals. The register restores therefore run before `set_fp` in the unwind stream, at an `sp` that has not been corrected. `saved.pas` (attached) is an ordinary non-leaf with an 8 KB buffer that needs x19-x23: ```asm stp x29,x30,[sp,#-16]! mov x29,sp stp x19,x20,[sp,#-16]! stp x21,x22,[sp,#-16]! str x23,[sp,#-16]! sub sp,sp,#2,lsl #12 str wzr,[sp,#4100] stp wzr,wzr,[sp] ``` ``` codes: [0] save_reg_x, [2] save_regp_x, [4] save_regp_x, [6] set_fp, [7] save_fplr_x 16, [8] end ``` `epi.pas` (attached) fills a context with sentinels, points it at a body PC in that function and calls `RtlVirtualUnwind`. The three addresses at the top differ from run to run; the register values do not: ``` sp = 00007FF633F44470 (correct) pc = 1234123412341234 (correct) fp = F00DF00DF00DF00D (correct) x19 = DEAD000000000004 (should be 0019001900190019) x20 = DEAD000000000005 (should be 0020002000200020) x21 = DEAD000000000002 (should be 0021002100210021) x22 = DEAD000000000003 (should be 0022002200220022) x23 = DEAD000000000000 (should be 0023002300230023) ``` The `DEAD...` values are the sentinels this test wrote into the local buffer: the registers are reloaded 8192 bytes below their real slots. `sp`, `pc` and `fp` survive because `set_fp` recovers `sp` from x29 afterwards - which is why an ordinary stack trace through such a frame looks entirely correct, and why this has gone unnoticed. ## Effect 2: large leaf functions get no .pdata entry at all A function whose only stack manipulation is the allocation emits no SEH directive, so `agcpugas.pas:463` (`if (handlerflags<>0) or (unwinddata.size<>0)`) skips the record. Per the specification a function without a `.pdata` entry is a leaf that does not touch `sp` and returns through `lr`. `leaf.pas` (attached) asks Windows through `RtlLookupFunctionEntry`: ``` LeafSmall (256 B): .pdata present LeafUnderPage (4000 B): .pdata present LeafOverPage (8192 B): no .pdata entry LeafHuge (65536 B): no .pdata entry ``` `vehtest.pas` (attached) shows what that costs: it faults inside such a leaf and reads the `sp` Windows would hand to the caller. For the 256 byte leaf the recovered value is right; for the 8192 byte one Windows keeps the faulting `sp`, which is the whole buffer too low (addresses vary per run): ``` leaf with an 8192 byte buffer SP at fault : 000000DB4BBFD960 caller SP : 000000DB4BBFF960 distance : 8192 bytes .pdata : MISSING -> Windows takes caller SP = 000000DB4BBFD960, off by 8192 bytes ``` `llvm-readobj --unwind` shows the same from the other side. For a non-leaf, where a record does exist, the allocation is simply absent from it: ``` Function: P$FRAMES_$$_NONLEAFOVERPAGE Prologue [ 0xe1 ; mov fp, sp 0x81 ; stp x29, x30, [sp, #-16]! 0xe4 ; end ] ``` That list is in unwind order, not machine order. The machine prolog is `stp x29,x30,[sp,#-16]!` / `mov x29,sp` / `sub sp,sp,#2,lsl #12`, and no code describes the `sub`. ## Patch `fpc-seh-stackalloc.patch` (attached) emits the directive on every path. It has to come after all of them, because `convert_unwinddata` reverses the directive order and the allocation must end up first in the code array. ## Please take #41870 first This patch makes the allocation the first unwind code for every frame of 4096 bytes or more, and those codes are multi-byte. The hardcoded epilog start index of 1 in `agcpugas.pas:509`, reported as #41870, then addresses their operand byte. On a compiler carrying only this patch: ``` local alloc 5104: c1 3f index 1 = 3f -> save_r19r20_x, a register restore that is not in the epilog local alloc 8176: c1 ff index 1 = ff -> reserved, invalid local alloc 4096: c1 00 index 1 = 00 -> alloc_s 0 local alloc 16368: c3 ff index 1 = ff -> reserved, invalid ``` So this patch should not ship on its own. The two touch different files and apply in either order; it is the landing order that matters - #41870 first, or both together. ## What this patch does not fix **Allocations that need a helper instruction.** Below 4096 and for sizes encodable as `imm12 lsl 12`, `handle_reg_imm12_reg` emits a single `sub`. Any other size becomes `movz x16,#size` / `sub sp,sp,x16`, and the epilog is `movz x16,#size` / `add sp,sp,x16`. One unwind code then describes two instructions, and a PC at the `sub` unwinds as if the allocation had already happened. Measured with a 6112 byte local allocation and x19-x23 in use: ``` +20 movz x16,#6112 OK +24 sub sp,sp,x16 FAIL - registers read from the buffer +28 str wzr,[sp,#2020] OK +32 str wzr,[sp] OK +36 body OK ``` I tried adding a `nop` code for the `movz` and it does not work, which is worth recording so nobody repeats it. The helper precedes the `sub` in the prolog and the `add` in the epilog, so the prolog needs the codes as `alloc, nop` while the epilog needs `nop, alloc` - and the array is reversed for the prolog only. Adding the `nop` makes the prolog PC above correct and breaks the epilog instead. On a leaf with a 5104 byte allocation, where no `set_fp` masks it: ``` without nop with nop movz (ret-8) OK OK add (ret-4) OK FAIL, sp 5104 bytes too low ``` A shared code array cannot describe both. The clean way out is probably the one the specification itself uses for this case: split the allocation into two directly encodable subtractions instead of loading the size into a register - the page multiple as `imm12 lsl 12` and the remainder as `imm12` - so that each gets its own allocation code. That is canonical form 6c/6e in the specification, `sub sp,sp,4080` followed by `sub sp,sp,#(locsz-4080)` described as `alloc_m` plus `alloc_s`/`alloc_m`. Both instructions then modify `sp`, the epilog mirrors them in reverse, and no `nop` is needed in either direction. It would also close the prolog PC above. I have not implemented it because it changes the generated code in both directions and that seemed like your call rather than mine. Until then the helper case is no worse than today, where the whole allocation is undescribed. **The probe loop.** From five pages up - `localsize div winstackpagesize > 4`, so 20480 bytes and more - `cgcpu.pas:1873` subtracts a page at a time at one address (`cgcpu.pas:1877`), so no fixed code sequence can express how many iterations have run. The patch emits the total there as well, which makes unwinding from the body right and gives the function a `.pdata` entry, but a PC inside the loop still cannot be described. Closing that means restructuring the probe to leave `sp` alone until one final `sub`, the way MSVC's `__chkstk` does. **The probe stores** have no codes of their own, and that turns out not to matter: they run after `sp` has reached its final value, so a PC at one of them unwinds through the complete sequence and comes out right. That holds for the merged `stp wzr,wzr,[sp]` the peephole optimiser sometimes produces as well. ## Verification Built from a copy of 416b51be87 with this patch and the one from #41870. `llvm-readobj --unwind` on the same test file reports ``` Prologue [ 0xc200 ; sub sp, #8192 0xe1 ; mov fp, sp 0x81 ; stp x29, x30, [sp, #-16]! 0xe4 ; end ``` and `0xe0001000 ; sub sp, #65536` for the 64 KB case. All four leaf functions get a `.pdata` entry, and `epi.exe` restores x19-x23 correctly. `prologpc.exe` goes from five failing prolog PCs to one, the helper case described above. The results that isolate this patch are the leaf `.pdata` entries and the register values - neither depends on the epilog index. ## Environment FPC 3.3.1 trunk 416b51be87, native aarch64-win64, Windows 11 26200 on a Snapdragon X Elite. The probing paths exist only for `system_aarch64_win64`, and the directive the patch adds is emitted under that condition too, so no other target is affected. Two notes for reproducing it. The test programs need `-O2`: they address prolog and epilog instructions by fixed offsets from the `ret`, so an unoptimised build measures the wrong instructions. And my verification compiler also carries four unrelated local fixes for this target (work items 41859 and 41865), without which a native aarch64-win64 build of trunk does not get far enough to run any of this - none of them touch SEH data, but the build is not stock. [fpc-seh-stackalloc.patch](/uploads/009dfcdd01e0b2a89d64e30ffc69860c/fpc-seh-stackalloc.patch) [fpc-seh-repro.zip](/uploads/82a0879f0df86651849e6fd1a0a62804/fpc-seh-repro.zip)