Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reorganize faulting stuff. Differentiate between arch- and OS-specific defines. #1449

Merged
merged 1 commit into from Nov 16, 2014

Conversation

comex
Copy link
Contributor

@comex comex commented Oct 31, 2014

Paging @Sonicadvance1. Please check that this doesn't break Android - assuming it compiles of course...

  • 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.

#ifdef ANDROID
#include <asm/sigcontext.h>
typedef struct sigcontext mcontext_t;
typedef struct ucontext {

This comment was marked as off-topic.

…c defines.

- 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.
@@ -9,7 +9,7 @@

namespace EMM
{
typedef u32 EAddr;
extern const bool g_exception_handlers_supported;

This comment was marked as off-topic.

This comment was marked as off-topic.

comex added a commit that referenced this pull request Nov 16, 2014
Reorganize faulting stuff.  Differentiate between arch- and OS-specific defines.
@comex comex merged commit aa2fc1f into dolphin-emu:master Nov 16, 2014
@comex comex deleted the memtools-merge branch November 16, 2014 18:46
stack_t uc_stack;
mcontext_t uc_mcontext;
// ...
} ucontext_t;

This comment was marked as off-topic.

@comex
Copy link
Contributor Author

comex commented Nov 17, 2014

I waited forever for someone to test it on Android, but :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants