Build is green on travis and appveyor

Branch is ready for review as it is green. Here were my issues that were resolved.

Issues

While Debug passes the tests and works for the most part, running in release has some serious issues which I have trouble fixing. This can be seen in travis tests.
The issue of Release is related to optimized builds. Even debug builds with an added -O1 flag have this issue.

This issue is also present in the original PR (#803).

My best guess at this is that optimized builds might either compile away some thunk call code or that the compiler uses different registers than non-optimized builds.

After doing some searching, I've tracked the obj file which is sensitive to -O1, it is constant_propagation_pass.o. If I compile xenia with -O1 and delete that obj file and recompile with -O0 then the tests run successfully. If I do this with any other file, the issue persists.
Here's the objdump of constant_propagation_pass.o with both -O0 and O1: https://gist.github.com/bwrsandman/d218a2d8590e5b74310cfd6dac8f234e

After more drilling down, it seems to come from some header included in constant_propagation_pass.cc. Clang has a pragma which disables optimization and by searching up the included headers, I found the highest single header for which disabling optimization fixes the problem. This header is src/xenia/cpu/hir/value.h. Something within this header is causing issues.

diff --git a/src/xenia/cpu/hir/value.h b/src/xenia/cpu/hir/value.h
index dcc95ca8..70a159fe 100644
--- a/src/xenia/cpu/hir/value.h
+++ b/src/xenia/cpu/hir/value.h
@@ -109,6 +109,7 @@ class Value {
   Use* AddUse(Arena* arena, Instr* instr);
   void RemoveUse(Use* use);
 
+#pragma clang optimize off
   void set_zero(TypeName new_type) {
     type = new_type;
     flags |= VALUE_IS_CONSTANT;
@@ -175,6 +176,7 @@ class Value {
     flags = other->flags;
     constant.v128 = other->constant.v128;
   }
+#pragma clang optimize on
 
   inline bool IsConstant() const { return !!(flags & VALUE_IS_CONSTANT); }
   bool IsConstantTrue() const {

The issue in within the set_zero() function of in src/xenia/cpu/hir/value.h. The following fixes the issue:

diff --git a/src/xenia/cpu/hir/value.h b/src/xenia/cpu/hir/value.h
index dcc95ca8..ae59a68e 100644
--- a/src/xenia/cpu/hir/value.h
+++ b/src/xenia/cpu/hir/value.h
@@ -109,7 +109,7 @@ class Value {
   Use* AddUse(Arena* arena, Instr* instr);
   void RemoveUse(Use* use);
 
-  void set_zero(TypeName new_type) {
+  void set_zero(TypeName new_type) __attribute__ ((optnone)){
     type = new_type;
     flags |= VALUE_IS_CONSTANT;
     constant.v128.low = constant.v128.high = 0;

The difference in opcode is here https://gist.github.com/bwrsandman/390712c2f29a7645f03e67d9daf8ce81

There are also similar issues happening on travis which I cannot replicate on my Arch setup with clang7. I am able to replicate these crashes on docker ubuntu 16.04 with clang6. Two solutions are available:

• Do the same work as above to find the offending functions
• Update travis to use clang7

The issues are similiar:

• Processor::backend() inlining was causing issues
• Value::Not() optimization was causing issues.

The issues are not clear and I am affraid that these are just hacks and not fixing the real underlying problems.

I am including this branch for review and for some helpful tips from the community since I haven't had the time to investigate this fully and didn't want to leave my partial work floating in the ether if someone wanted to pick up this particular task.

So, in that specific function the difference between optimizing and not is the usage of AVX instructions.
What were the issues, exactly? Crashes? Clobbering?

So, in that specific function the difference between optimizing and not is the usage of AVX instructions.
What were the issues, exactly? Crashes? Clobbering?

Clang 6 would vectorize the arguments inside a different register in Release than in Debug. This led to inconsistent behavior depending on the optimization level.

Rebased onto master and added the comment as per @DrChat request

@Margen67 cpu would be a better tag than test since the tests are testing the ppc cpu emulation :P

The exception handler part has been merged into the main branch — thanks @uytvbn! 💚 I've also added RIP updating after an exception handler as that's needed for MMIO (it executes the mov manually and advances the instruction pointer). One additional change that I've made though is questionable — the original commit had bit 1 << 1 of the error code for a SIGSEGV interpreted as "read access violation" when it's set. However, asm/trap_pf.h (not doing an #include of it though as it's not available on Android apparently) says that it's the opposite — X86_PF_WRITE is set to 1 for a write page fault. Which behavior is correct in this situation?