[fpc-devel] Subject: six issues from a native aarch64-win64 port (three of them not target specific)

[Sven Barth]

Am 25.08.2026 um 12:31 schrieb Sven Harazim via fpc-devel:
> 41870  https://gitlab.com/freepascal.org/fpc/source/-/work_items/41870
>    The epilog start index in the .xdata header is written as 1, but the field is
>    a byte index into the unwind code array. With a two-byte first code, index 1
>    addresses its operand byte: a 4016-byte frame gives c0 fb ..., and the
>    unwinder starts the epilog scope at 0xfb - llvm-readobj calls that a bad
>    opcode. For other sizes the operand byte is a valid code and is executed as
>    one: 0x3f decodes as save_r19r20_x.
>
> 41871  https://gitlab.com/freepascal.org/fpc/source/-/work_items/41871
>    At or above one page of locals the allocation goes through the probing path,
>    where no ash_stackalloc is emitted, so it is missing from the .xdata
>    altogether. A routine with no other unwind-relevant prologue operation then
>    gets no .pdata entry at all - which per the specification means a leaf that
>    does not touch sp and returns through lr. The defect is independent of 41870,
>    but the patch depends on it landing first: it makes the allocation the first,
>    multi-byte code for every such frame, which is exactly the case 41870
>    mis-indexes. Measured on a compiler carrying only the 41871 patch, a
>    5104-byte frame gives c1 3f, and index 1 executes the 0x3f as
>    save_r19r20_x.
Do you have tests instead of showcases (or reproductions as you call 
them) for these two? Something that I can stuff into FPC's testsuite 
that will fail without these fixes and does not with the fixes applied? 
(preferrably one for each issue)

Regards,
Sven