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

[Sven Harazim]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tw41870.pp
Type: application/octet-stream
Size: 5594 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20260826/3f60b45e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tw41871.pp
Type: application/octet-stream
Size: 4887 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20260826/3f60b45e/attachment-0001.obj>