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
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
