There was a longstanding hack that defined ucontext_t manually to work
around the lack of this header on the Android NDK. However, it looks
like newer NDK versions now have it like good little POSIX boys, and my
recent header reshuffle broke the build on those versions, presumably
because the real and fake definitions of ucontext_t end up included in
the same file where they weren't under the old organization.
Rather than try to revert the conflict, this commit just removes the
hack. The buildbot's NDK will need to be upgraded.
Regression by 3fed975bac caused netplay to
crash on OS X. While I'm at it, fix the long-standing "unsafe i guess"
AddPendingEvent, since we depend on wx 3 now...
Changing PATH basically screws everything up, and while the attempt to
avoid MacPorts copies of system libraries was well-intentioned, it made
the OS X buildbot unable to pick up ffmpeg and libusb.
It's sufficient to put /usr first to make sure we use the system copies
of duplicated libraries.
m_strGPUDeterminismMode can be set by either the global or game
settings. Either way, it's then supposed to be parsed into an enum,
m_GPUDeterminismMode. However, the code to do this was placed right
after checking for game settings, which doesn't happen at all if there
isn't a valid title ID. Move it outside the if block.
- Get rid of ArmMemTools.cpp and rename x64MemTools.cpp to MemTools.cpp.
ArmMemTools was almost identical to the POSIX part of x64MemTools, and
the two differences, (a) lack of sigaltstack, which I added to the
latter recently, and (b) use of r10 to determine the fault address
instead of info->si_addr (meaning it only works for specifically
formatted JIT code), I don't think are necessary. (Plus Android, see
below.)
- Rename Core/PowerPC/JitCommon/JitBackpatch.h to Core/MachineContext.h.
It doesn't contain anything JIT-specific anymore, and e.g. locking
will want to use faulting support regardless of whether any JIT is in
use.
- Get rid of different definitions of SContext for different
architectures under __linux__, since this is POSIX. The exception is
of course Android being shitty; I moved the workaround definition from
ArmMemTools.cpp to here.
- Get rid of #ifdefs around EMM::InstallExceptionHandler and just
provide an empty implementation for unsupported systems (i.e.
_M_GENERIC really). Added const bool g_exception_handlers_supported
for future use; currently exception handlers are only used by the JIT,
whose use implies non-M_GENERIC, but locking will change that.
- Remove an unnecessary typedef.
This is a higher level, more concise wrapper for bitsets which supports
efficiently counting and iterating over set bits. It's similar to
std::bitset, but the latter does not support efficient iteration (and at
least in libc++, the count algorithm is subpar, not that it really
matters). The converted uses include both bitsets and, notably,
considerably less efficient regular arrays (for in/out registers in
PPCAnalyst).
Unfortunately, this may slightly pessimize unoptimized builds.
std::array does not have an initializer list constructor, instead (for
some reason) being defined to contain one public array member, allowing
it to be directly initialized. Thus the most explicit way to initialize
it is with two braces, one for the struct and one for the array. C++
allows the second pair of braces to be omitted, but clang complains
about it.
This is good hygiene, and also happens to be required to build Dolphin
using Clang modules.
(Under this setup, each header file becomes a module, and each #include
is automatically translated to a module import. Recursive includes
still leak through (by default), but modules are compiled independently,
and can't depend on defines or types having previously been set up. The
main reason to retrofit it onto Dolphin is compilation performance - no
more textual includes whatsoever, rather than putting a few blessed
common headers into a PCH. Unfortunately, I found multiple Clang bugs
while trying to build Dolphin this way, so it's not ready yet, but I can
start with this prerequisite.)
I found it via clang complaining about a useless null check on an array,
but I decided to get rid of the array in favor of dynamic allocation, as
there was no reason to assume a maximum length of 0x32 bytes. Plus, add
a CFString type check just in case, and switch to UTF-8 in the
off-chance it matters.
The result has not actually been tested, as I have no CD drive.
The latter was introduced last year in order to allow debugging without
turning off Fastmem; I wanted to see if the old way was faster. In
fact, it is not, but may as well keep the define around in case future
testing is necessary.
In the unlikely case that it tripped and then, due to a bug, some other
fault occurred (e.g. stack misalignment), Dolphin would go into an
infinite loop rather than crashing.
comex