> 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)
Yes - two attached, one per issue, both in webtbs form and both self-checking: tw41870.pp and tw41871.pp. Rename and renumber as you like. Built four compilers from one tree, differing only in which patch is applied, all runs at -O2: compiler tw41870 tw41871 stock exit 1 exit 1 only 41870 exit 0 exit 1 only 41871 exit 1 exit 0 both exit 0 exit 0 so each test isolates its own fix rather than the pair. How they work: neither test runs the function it is about. Both hand RtlVirtualUnwind a fabricated CONTEXT positioned at a chosen instruction of a compiled function and check that the caller's sp and return address come back. Nothing depends on the real stack, on ASLR or on which thread runs them. Why they isolate. tw41870 uses a 4016 byte frame, below a page, so the allocation does not take the probing path and its unwind code is emitted even on stock trunk - the only thing that can go wrong there is the epilog scope starting one byte into the two-byte alloc_m. tw41871 deliberately probes a *body* pc, which is described by the prolog codes and never touches the epilog scope, so it passes as soon as the allocation is emitted at all, with or without the 41870 fix. Sample failures on stock trunk: tw41870: add sp,sp,#4016: sp is 00007FF6BD7CFB90, expected 00007FF6BD7D0B50 add sp,sp,#4016: return address is BADBADBADBADBAD0, expected 1234... tw41871: no .pdata entry: Windows takes this function for a leaf that does not touch sp Both tests find their prolog and epilog by instruction encoding, bounded by the function's ret, and exit with 2 and "shape not recognised - this test needs updating" if the code generator stops emitting that shape. Since the suite has no runtime skip, that seemed better than silently passing forever; the distinct exit code is meant to tell "test is stale" from "defect is back" in the log. It earned its keep already - it caught a change I made to the test function itself that had shifted the epilog. One thing you may want to know independently of these two: the windows unit has no ARM64 CONTEXT. wininc/struct.inc defines one for i386, x86_64 and powerpc32, and everything else falls into the placeholder that declares TContext as an empty record. That is why the tests carry the field offsets as constants. It also means GetThreadContext and anything else taking a TContext is unusable on aarch64-win64 today. Regards, Sven Harazim
tw41870.pp
Description: Binary data
tw41871.pp
Description: Binary data
_______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
