fix(verify): gate JIT verification to amd64 until trampolines are hardened
Test / vet (push) Successful in 48s
Test / test (push) Successful in 2m34s
Test / build (push) Successful in 41s

This commit is contained in:
2026-08-30 22:48:48 +02:00
parent 9cb1666b35
commit a5a59d6503
15 changed files with 206 additions and 30 deletions
+12 -10
View File
@@ -43,16 +43,18 @@ Unreleased changes on the `development` branch.
architectures via hand-written assembly trampolines
(`trampoline_{arm64,riscv64,loong64}.s`) that save the Go stack, switch
to a prepared stack, and branch to the JIT function.
- **ABI checks on all architectures.** `gasm verify -abi` and the ABI
half of `-fuzz` now work on arm64, riscv64 and loong64 via
per-architecture checked trampolines: sentinels planted in the
registers the Go ABI fixes across calls (amd64 `BP`/`R14`, arm64
`R29`/`R28`, riscv64 `X27`, loong64 `R22`) are verified on return, with
the below-SP canary on every architecture. `gasm verify` now runs the
JIT checks whenever the host matches the kernel's architecture, and
takes the ground-truth-only path only on other hosts. The `ABIReport`
fields are renamed to the architecture-neutral `FPClobbered` and
`GClobbered`.
- **ABI checks architecture port (partial).** The ABI-checking
machinery is architecture-neutral (`ABIReport` with `FPClobbered`,
`GClobbered`, `RedZoneHit`; renamed from the amd64-only field names)
and per-architecture checked trampolines exist for arm64, riscv64 and
loong64 alongside amd64, restoring the frame pointer and the goroutine
pointer before returning into Go code. Runtime execution of the
non-amd64 JIT paths is not yet reliable (arm64 and loong64 fault on the
return path and riscv64 returns a wrong result under qemu-user), so
`gasm verify` keeps JIT execution gated to amd64 kernels on amd64
hosts; other kernels take the toolchain-comparison path exactly as
before. A qemu-user harness and GOARCH-guarded tests are in the tree
to validate the trampolines once their return path is fixed.
- **Hardware watchpoints on all architectures.** arm64 uses DBGWVR/DBGWCR
via `PTRACE_SETREGSET` with `NT_ARM_HW_BREAK`; riscv64 and loong64 use
`PTRACE_POKEUSER` to access trigger/debug registers.