# [Patch] aarch64-win64: hardcoded epilog start index splits a multi-byte unwind code `compiler/aarch64/agcpugas.pas:508-509` builds the `.xdata` header as ```pascal unwindrec:=unwindrec or (1 shl 21); { E bit - single epilog } unwindrec:=unwindrec or (1 shl 22); { epilog start index = 1 } ``` With `E=1`, bits 22-26 hold the epilog start index. The specification describes the header field only as "the index of the first unwind code that describes the one and only epilog", but it is a **byte** index: the explicit epilog scope word used when `E=0` spells that out - "the byte index of the first unwind code that describes this epilog" - and both `llvm-readobj` and the Windows unwinder treat the packed field the same way, as the measurements below show. The value 1 is written unconditionally, without regard to how long the first code is. When that code is longer than one byte, the index addresses its operand byte, which the unwinder then decodes as an opcode of its own. ## The failure The programs named below are in `fpc-seh-repro.zip`, attached here and to the companion report; `README.txt` in it says what each one shows and how to build them. They need `-O2`. `llvm-readobj --unwind` on a function with a 4016 byte frame: ``` EpilogueOffset: 1 Prologue [ 0xc0fb ; sub sp, #4016 0xe1 ; mov fp, sp 0x81 ; stp x29, x30, [sp, #-16]! 0xe4 ; end ] Epilogue [ 0xfb ; Bad opcode! 0xe1 ; mov sp, fp 0x81 ; ldp x29, x30, [sp], #16 0xe4 ; end ] ``` `0xfb` is the operand byte of `alloc_m` and is not an unwind code. `epi.pas` (attached) hands `RtlVirtualUnwind` a context at each instruction of that epilog and compares the result with the known correct values. Abridged - the run prints the addresses too, and those differ every time: ``` NonLeafUnderPage (codes c0 fb e1 81 e4, index 1 points inside alloc_m): body (ret-20): OK body (ret-16): OK add (ret-12): FAIL sp off by -4032, pc = BADBADBADBADBAD0 mov (ret-8) : FAIL sp off by -16, pc = BADBADBADBADBAD0 ldp (ret-4) : FAIL sp off by -16, pc = BADBADBADBADBAD0 ret (ret-0) : OK ``` Three of the four epilog instructions unwind to a wrong `sp` and a wrong return address. The operand byte does not always decode as an invalid opcode. It can also be a different valid one, in which case the unwinder performs a stack operation that was never in the epilog. Whether that is visible depends on what follows: a later `set_fp` can mask a wrong `sp`, while a bogus register restore cannot be undone. The metadata is wrong in every one of these cases. The damage is not confined to the epilog either. Because the scope is derived by counting operations from the start index, decoding from mid-code can yield *more* operations than the real epilog has, and the inferred scope then reaches backwards over instructions that belong to the function body. Those then unwind with epilog rules and give a wrong `sp` as well. ## Why it has survived Where the first code is a single byte, index 1 is functionally invisible. The same test on two such functions passes at every offset: ``` NonLeafSmall (codes 10 e1 81 e4, index 1): OK at all six offsets LeafSmall (codes 10 e4 e3 e3, index 1): OK at all three offsets ``` With `E=1` the record carries no explicit epilog start offset. Windows anchors the single epilog at the end of the function and derives its start by decoding from the given byte index and counting unwind operations through `end`, which also accounts for the `ret`. Skipping exactly one one-byte code therefore describes an epilog one instruction shorter, and that first instruction is unwound as body code - where the full sequence from index 0 runs and produces the same caller state. So today the defect needs a first code of two bytes or more. On a local allocation that means 512 bytes or more, where the one-byte `alloc_s` gives way to the two-byte `alloc_m`. Above 4095 there is no allocation code at all on current trunk - that is the other report - so `alloc_l` only becomes reachable as a first code once that one is fixed. Saved-register codes such as `save_reg_x` and `save_regp_x` are two bytes as well, and become the first code when a function saves registers but allocates no locals. ## Patch `fpc-seh-epilogindex.patch` (attached) drops the line, leaving the field at 0. The unwind codes from index 0 describe the teardown of the epilogs FPC generates: `add sp,#n` / `mov sp,x29` / `ldp x29,x30,[sp],#16` / `ret` against a prolog of `stp` / `mov x29,sp` / `sub sp,#n`. That is the case the E bit exists for, so `E=1` itself is right; only the index was wrong. I looked for a compiler-generated epilog whose teardown is not described by the sequence from index 0 and did not find one. Frame sizes that need a `movz` helper still end in a single `sp`-modifying instruction, `potype_exceptfilter` epilogs match their prologs, and `nostackframe` produces no record at all. The one prolog that is genuinely not mirrored is the stack probing loop, which subtracts a page at a time while the epilog adds the total once - but that concerns the prolog side and is the subject of the separate report below. ## Please take this one first There is a one-way dependency with the other aarch64-win64 unwind report, the missing `ash_stackalloc` on the stack probing path. That patch makes the allocation the first unwind code for every frame of 4096 bytes or more, and those codes are multi-byte. Applied on its own it would therefore turn functions that are unaffected today into ones where index 1 splits a code. Measured on a compiler carrying only that patch: ``` frame 5104: c1 3f index 1 = 3f -> save_r19r20_x, a register restore that is not in the epilog frame 8176: c1 ff index 1 = ff -> reserved, invalid frame 4096: c1 00 index 1 = 00 -> alloc_s 0 frame 16368: c3 ff index 1 = ff -> reserved, invalid ``` The two source patches touch different files and apply in either order, but this fix should land first, or both together. ## Verification Built from a copy of 416b51be87 with this patch and the one from the companion report. `EpilogueOffset` is 0 throughout, and `epi.exe` goes from 6 failures out of 19 checks to 0. The three that this patch alone accounts for are the `NonLeafUnderPage` epilog instructions above, which fail on stock trunk without any other change; the other three are the large leaf covered by the companion report. 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 reports failures either way. 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. ## Environment FPC 3.3.1 trunk 416b51be87, native aarch64-win64, Windows 11 26200 on a Snapdragon X Elite. `TransformSEHDirectives` runs only under `system_aarch64_win64`, so no other target is affected. [fpc-seh-epilogindex.patch](/uploads/20ac76b0cd7f8441b31260a685ed3659/fpc-seh-epilogindex.patch) [fpc-seh-repro.zip](/uploads/9e4cd36c0c73e36615e7296cb45a5216/fpc-seh-repro.zip)