Significantly Expand Gecko Code Size Limit

[LittleCoaks]

This feature works by manipulating the Arena to increase the gecko code size limit. The codelist size is computed, then ArenaHi is lowered by that amount, and the codelist is placed above the Arena. This functionally makes the gecko code size limit as large as reasonably possible for any game (significantly larger than the current limit).

This feature hinges on ArenaHi always being located at 0x80000034 which is true for all gamecube games from my research. I have not looked into other platforms supported on dolphin.

This PR is intentionally left incomplete because there are design considerations with this feature that i left up to the dolphin development team to decide on first before moving forwards, like for example, guarding this behavior with a user configuration defaulted to disabled. Worth noting as well, netplay would likely need to have such a configuration synced between clients to avoid possible desyncs.

[phire]

It can't be valid to adjust ArenaHi after the game is already running? What if the game already has memory allocated there?

[VampireFlower]

@phire Testing using GFTE01, arenaHi is already overwritten with the new value before its first use in __start, which runs before main. The overwrite occurs while __init_bss_section is running. It is worth verifying this beyond a sample size of one game.

[phire]

This code appears to run from the vblank handler.

With it's async nature, I'm not sure it's valid to assume it will always run before __start. The "while __init_bss_section is running" is exactly what I'm concerned about.

[LittleCoaks]

@phire do you know of a better way to handle it with dolphin's tools? from the games i've tested with it's always successfully manipulated the arena with no problems, however i don't know how to go about a decisive/thorough test that ensures __start is never hit before the overwrite with this method. I've personally found great value in this feature so far from using it however, so at the very least, i think it's worth considering for an "Advanced" user configuration defaulted to disabled if we can't guarantee it's always safe