These tends to get requested from either pure GDB or Ghidra. They reduce the verbosity of the communications. The QSupported packet is also important to implemnent for future proofing too.
The stub was made with the assumption that the GDB architecture is rs6000:6000, but the closest is actually powerpc:750 which features much more SPR that the gekko supports, but it also has slightly different ID. This commit now assumes the more proper powerpc:750.
It's always a good sign when the comments say "this will definitely
crash" and "I don't know if this is for a good reason".
Fixes https://bugs.dolphin-emu.org/issues/12762.
These GetPointer calls could cause crashes, in part because the
callers didn't do null checks and in part because GetPointer
inherently is unsafe to use for accesses larger than 1 byte.
The actual values don't matter since we overwrite all of the relevant fields, but other bits were not initialized (e.g. the top 12 bits of X10Y10), so the warning was semi-valid.
This piece of code is rather hard to understand, but my best guess
at what it's trying to do is that it tries to create opportunities
to skip writing CRs back to ppcState if we know that there are no
CR instructions (or branch instructions, etc) between an instruction
that writes to a CR register and the next blr. This is technically
inaccurate emulation, but as long as games don't do anything too
weird with their ABIs, I suppose it doesn't break anything.
So why do I want to get rid of it? Well, other than breaking some
hypothetical weird game, I imagine it could trip up people trying
to debug a game who are looking at the CR contents. And the code
is just plain confusing. (blr clearly doesn't write to CRs!)
Previously, EFB copies would be in the middle of other objects, as objects were only split on primitive data. A distinct object for each EFB copy makes them easier to spot, but does also mean there are more objects that do nothing when disabled (as disabling an object only skips primitive data, and there is no primitive data for EFB copies).
This also adds the commands after the last primitive data but before the next frame as a unique object; this is mainly just the XFB copy. It's nice to have these visible, though disabling the object does nothing since only primitive data is disabled and there is no primitive data in this case.
