Emulator

Game Name?

N/A

Game ID? (right click the game in the game list, Properties, Info tab)

N/A

MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)

N/A

What's the problem? Describe what went wrong.

Currently, Dolphin's codehandler.s has a bug with setting grN (gecko register #) and bP (gecko block #).
It sets grN and bP starting from .long frozenvalue, which is incorrect, as the space left for grN and bP is 156 bytes, as specified by .space 39*4.
This causes code handler to overwrite .long frozenvalue. Apparently, this is harmless (for how long this has gone unnoticed) but is technically incorrect.
The current algorithm for getting the offsets do not take account for .long frozenvalue:

• For grN it seems to be cheatdata + (grN * sizeof(uint32_t)).
• For bP it seems to be cheatdata + ((sizeof(uint32_t) * (1 + 0xF)) + (bP * (sizeof(uint32_t) * 2))).

After the 156 bytes (.space 39*4), you can see 9421FF54 which is the first line of _start: stwu r1,-172(r1). _start comes right after .space 39*4. This means .long frozenvalue is NOT part of .space 39*4 but the bug is that the code handler is calculating offsets without taking into account .long frozenvalue and therefore treating it as part of .space 39*4.

What steps will reproduce the problem?

Run this gecko code below on ANY game, view memory in Dolphin Memory Engine, then go to start of code handler at 0x80001800, then view the first three uints, the third uint (which should be a pointer to the start of frozenvalue: which occurs after the code of the code handler itself) shown as 0 which is the bug.

$TEST_CODE
60000000 00000000

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

5.0-20128

Is the issue present in the latest stable version?

Unknown where it started in stable, but I tested it in Legacy versions Dolphin 5.0 AND Beta versions 5.0-19870 and this happened.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

N/A

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

N/A

What are your PC specifications? (CPU, GPU, Operating System, more)

Windows 10 Enterprise LTSC 64-bit (10.0, Build 19044) (19041.vb_release.191206-1406)
11th Gen Intel(R) Core(TM) i7-11700KF @ 3.60GHz (16 CPUs), ~3.6GHz
Micro-Star International Co. Ltd. Z590 PRO WIFI [CEC] (MS-7D09) (U3E1)
32.0GB RAM (32768MB RAM, 32650MB RAM available)
HP 24m (1920x1080@60Hz)
2047MB NVIDIA GeForce RTX 3080 (MSI)
953GB MSI M370 1TB (Unknown (SSD))

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

For screenshots:

• 156bspace.png: These are the 156 bytes starting AFTER .long frozenvalue (.space 39*4 = 156 bytes after .long frozenvalue).
• frozenvalue160bspace.png: These are the 160 bytes if writing from .long frozenvalue, which is incorrect ([160 bytes which includes both .long frozenvalue and .space 39*4]).