Emulator Issues #13686
open
[JIT] Register values are stale when evaluating conditional MBP
0%
Description
Game Name?
Mario Golf: Toadstool Tour
Game ID?
GFTE01
MD5 Hash?
5fd9909e73df7fb704d2e443e17346b5
What's the problem? Describe what went wrong.
A memory breakpoint is breaking when the condition is false.
What steps will reproduce the problem?
Proceed past the main intro sequence and to the title screen. Place a write breakpoint on memory address 802D7C8C with the condition: "r3 != 0". The breakpoint will then break on the next frame, despite the value of r3 being 0 when the instruction writing to the memory location is executed.
The instruction it breaks on will be 8001E910 stw r3, -0x7BD4 (r13). The value of r3 will be 0.
Inspecting logs displays a contradiction:
59:36:711 Core\PowerPC\Expression.cpp:491 N[MI]: Breakpoint condition returned: 1. Vars: r3=1
59:36:711 Core\PowerPC\BreakPoints.cpp:395 N[MI]: MBP 8001e910 ( --- ) Write32 0 at 802d7e8c ( --- )
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes. 2412-8
Is the issue present in the latest release? For future reference, please also write down the version number of the latest release.
Yes. 2412
If the issue isn't present in the latest release, which is the first broken version?
Bug has been present ever since conditional MBPs were implemented (5.0-18019).
What are your PC specifications? (CPU, GPU, Operating System, more)
Core i9 12900h, RTX 3070 Ti Laptop GPU, 40GB Ram, Windows 11 23H2.
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
Dual core was disabled for all testing.
I tested using the Interpreter (slowest) option for CPU emulation engine, and encountered the same behavior.
Files
Updated by VampireFlower 17 days ago
Typo in the post, 802D7C8C should be 802D7E8C
Updated by taolas 9 days ago
It's likely the register information is old, because the value recently changed and it hasn't updated. You can hopefully fix it with Top menu -> Jit -> LoadStore Off. If that doesn't work try setting the other options to Off there.
If that has no effect, let me know.
Jos said "Maybe we could use a faked DSI exception to exit the JIT block" (Pausing/Breaking updates the info, so I think this would simulate that without pausing).
Updated by VampireFlower 8 days ago
Toggling JIT -> JIT LoadStore Off ON fixes the bug and results in intended behavior.
Updated by JosJuice 8 days ago
- Subject changed from Incorrect evalutation of conditional MBP to [JIT] Register values are stale when evaluating conditional MBP
- Status changed from New to Accepted
What I was talking about more specifically is that if we're in the middle of a JIT block while the code that evaluates the breakpoint condition tries to read register state from m_ppc_state, the JIT may not have written the register state back to the m_ppc_state, causing it to read back a stale value. If JIT LoadStore Off fixes the problem you're experiencing, that confirms that this is the problem. But you would also need to set JIT LoadStore Floating Off and JIT LoadStore Paired Off for it to work with all kinds of load/store instructions.
The register values being updated in the GUI when you pause emulation is unrelated to this. What matters is the register values being updated in m_ppc_state, which always happens when a JIT block exits, and can be made to happen in the JIT under other conditions too if required, such as when falling back to the interpreter (which is what JIT LoadStore Off ends up doing). Updating register values in m_ppc_state when calling into C++ for a slow memory access would be simpler and possibly also more efficient than trying to exit the block early using a faked DSI exception. I will look into this.