A game could wild pointer into a slightly out of range part of the sealed heap during init, and then do so differently on a subsequent init, and we wouldn't detect it
The existing code had a lot of copy paste and things that needed to be done twice to keep both impls in sync. Refactor to use a minimal abstraction layer and keep all other code common
What _was_ this? A new categoryLabel abstraction was added so we'd need fewer hacks, but in order to use it you need to add extra hacks to it per core? Nonsense code, too. Fix it properly. (Maybe; I didn't test it. Why bother? No one else puts any effort into this either.)
The goal here is to provide an unwind implementation that works. We (probably) don't have a working ldso, so reconfigure libunwind to work without that. To do that, it needs __eh_frame_* variables which it can addressof to find the locations of .eh_frame and .eh_frame_hdr. There is no way I could get gold to add these at all, so switch back to ld and add a custom linkscript. The custom linkscript gives us the opportunity to simplify the savestate memory mapping stuff inside ElfLoader, which should knock a bit of time off of state loads -- those VirtualProtect calls are not cheap. This also removes a potential source of nondeterminism with certain clever out of range pointers.
Any waterbox core that I didn't recompile for this commit will assert now until it is recompiled, because .wbxsyscall is in the wrong palace.
The refactoring of platform abstractions should never have changed the name of the public interface. No one cares about MemoryBlockWindows or MemoryBlockUnix - those names are impl details.
Trigger condition: Any 32x rom smaller than 4MB in total size that tries to read out of bounds between its actual end and the 4MB limit
I've fixed the emulator crash, but I do not know if such roms are actually mirroring correctly - they probably aren't
Create an all new waterbox build environment:
WSL2 + Ubuntu 20.04 LTS (Other linuxes may work)
Musl libc with waterbox customizations
LLVM's libclang-rt, libunwind, libcxxabi, libcxx
Static linking to elf files
Compared with the old system, this is easier to set up a dev env for and easier to update in the future. The executables are larger but produce smaller savestates due to static linking. The modern toolchain means advanced library features and language features that sometimes appear in some upstream cores will be reusable.
nattthebear