mirror of
https://github.com/ARMSX2/ARMSX2.git
synced 2026-08-24 16:50:16 -07:00
bmdhacks
9eb45cf590
`mVU_XGKICK_` splits a packet that runs past the top of VU1 memory in two: the pre-wrap head goes to `Gif_Path::CopyGSPacketData`, and only the post-wrap tail goes to `Gif_Unit::TransferGSPacketData`. The PCSX2_RECOMPILER_TESTS sink hooked only the second one, so a wrapped kick was captured as its tail alone — no GIFtag at all. Measured while landing the console XGKICK cases: 64 captured bytes from the recompiler against 112 from the interpreter, which loops through TransferGSPacketData and never calls CopyGSPacketData. That reads exactly like a serious microVU miscompile and is entirely our instrumentation; both engines emit the same correct stream. CopyGSPacketData now feeds the same sink and skips the ring, since nothing drains it while the sink is installed. The gif_test_hooks declaration moves above Gif_Path so the member function can see it. Consequence, which is larger than the bug: before this, no test could observe a wrapped XGKICK's GIFtag. Every XGKICK test used packets that fit inside VU1 memory, so the blind spot never showed. Test-build only — the whole block is inside #ifdef PCSX2_RECOMPILER_TESTS. vu1_xgkick_drain_tests.cpp moves with it. That file is ours and postdates the branch this came from, and its wrap case was written against the blind spot: it asserted the JIT capture was the 32-byte tail, with a header comment explaining that the head was unreachable. Both halves now arrive, so it asserts the whole 48 bytes — head carrying the GIFtag, tail resuming at offset 0 — which is the stronger property and the one that was never testable before. The XgKickHack wrap case already asserted that shape and only loses a stale "unlike the non-hack path" aside. Idea by pstef.