This broke any waterbox core that called in to native code in the same EnterExit() right after sealing. All nyma cores were broken, 32x was not, didn't check the rest. Regressed in 175556529e.
It worked fine in release mode, theoretically
Set up a second mirror of guest memory; easily accomplished because we were already using memfd_create / CreateFileMappingW.
This lets us simplify a lot of host code that has to access guest memory that may not be active right now, or might have been mprotect()ed to something weird. Activate is only needed now to run guest code, or when the C# side wants to peer into guest memory for memory domains and such (waterboxhost does not share the mirror address with the C# side).
Bizhawk never would hit this because it only ever runs waterboxes in one host thread, but an application that spun up many threads and ran waterboxes in each would leak 32 bytes of heap for each native thread destroyed, which is super duper not really meaningful at all
Waterbox guest code now runs on a stack inside the guest memory space. This removes some potential opportunities for nondeterminism and makes future porting of libco-enabled cores easier.
This replaces the old managed one. The only direct effect of this is to fix some hard to reproduce crashes in bsnes.
In the long run, we'll use this new code to help build more waterbox features.
Cores that used the .invisible section to store data were saving it; this was a regression from before, so PCFX states should be back down to the previous release size, or perhaps a bit smaller.
Add the ability to dirty track libco cothreads, as used in the bsnes core. This saves a lot of space in those states and they're now quite competitive in size.
some bsnes cothreads call callbacks that hit managed threads. We shouldn't do that, but we do, and sometimes those threads run MSVC's __stkchk which can, depending on circumstances, blow up if the thread extents aren't set.
This also means that we cannot save space on a lot of cothread stacks because __stkchck will blow up any detection guards we try
The waterbox system now uses host os facilities to track whether memory has been written to, to automatically choose what thing to savestate. This results in a large size decrease for some cores, like snes9x or gpgx (when running cartridge games). Doesn't do much for cores that were already memory efficient, or for bsnes because of libco compatibility issues; but those cores don't regress either.
nattthebear