(05-02-2018, 08:21 AM)Gerdya Wrote: The next crashes have to do with code generation. I did figure out the following as far:
1) X28 is used as memory base address
2) It is intialized in JitAsm.cpp (note MEM_REG = X28)
// set the mem_base based on MSR flags
LDR(INDEX_UNSIGNED, ARM64Reg::W28, PPC_REG, PPCSTATE_OFF(msr));
FixupBranch physmem = TBNZ(ARM64Reg::W28, 31 - 27);
MOVP2R(MEM_REG, Memory::physical_base);
FixupBranch membaseend = B();
SetJumpTarget(physmem);
MOVP2R(MEM_REG, Memory::logical_base);
SetJumpTarget(membaseend);
Indeed, the content of X28 is equal to logical_base, so this works. However *logical_base is not accessible -> so i get an access violation on each load and store using X28.
I do see where physical_base is allocated/comitted, however i do not see where logical_base is allocated or comitted. Any hints?
This is a memory failure which happens on purpose. We call it fastmem. There is a nice article about it in https://www.alchemistowl.org/pocorgtfo/pocorgtfo06.pdf (warning: 100mb) Edit: It is on page 9: 3.4 Dolphin intentionally makes thousands of segfaults
Does dolphin also crash if it is not within a debugger? If so, you can disable this feature with an ini setting:
Dolphin.ini
[Core]
Fastmem = False
This will slow down a lot, but still a lot faster than the interpreter.