mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-08-31 17:55:23 +02:00
Henrik RydgårdandClaude Opus 5
c0545658bc
Only one step can be carried out per pass through Core_ProcessStepping(), so roughly one per host frame. A second request arriving before that was rejected outright - "Can't submit two steps in one host frame" - with no step performed, which put the burden on every caller to notice and retry. A script firing five cpu.stepInto in a row advanced one instruction and logged four errors. They queue now, up to 8 deep; past that something is looping and it says so rather than growing without bound. Five stepIntos advance five instructions. The queue is deliberately *not* cleared by Core_Break(). That looks like the obvious place for it - stopping for another reason should abandon a pending plan, the way the temporary breakpoint and the runUntilTime deadline are dropped there - but completing a step-over or step-out goes *through* Core_Break(), since their temporary breakpoint is what stops us. Clearing there would throw away everything after the first entry of any sequence. It's cleared on CoreLifecycle::STARTING instead, so a step queued against the game that just went away can't run against the new one. g_cpuStepCommand keeps its existing double duty as both "the step in flight" and "why we're stopped" (reason/relatedAddr, read by Core_GetSteppingReason), so Core_Break()'s override check for an in-progress Over/Out is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GZq8ZtJmFY7bkX5FVkr3P9