(05-14-2018, 08:24 PM)degasus Wrote: [ -> ]Maybe we violate something in the ABI specs and some windows syscall overwrites our stack. We use the stack in a non-common way, with propper stack guards or anything similiar.
Yes indeed - at the moment i am trending to some data corruption, either globals or stack.
Currently i am writing out 2 kind of logs:
[color=#000000]
1) [/color][color=#000000]
e:\dolphin-master-org\dolphin\source\core\core\powerpc\jitarm64\jit.cpp:562 D[JIT] ....along with full PPC state.[/color]
From what i understand this log is written each time a new Jit-Block is generated.
[color=#000000]
2) [color=#000000]e:\dolphin-master-org\dolphin\source\core\core\memtools.cpp:39 N[JIT]: EXCEPTION: CODE:c0000005 ACCESSTYPE: 0 BADADDRESS:00000002CC005020[/color][/color]
T[color=#000000]
[color=#000000][color=#111111]his is written on each exception and is typically handled by fastmem_handler, which inserts a trampoline to the proper C-functions - i intensively reviewed most of the code and could not find anything suspicious.[/color][/color][/color]
[color=#000000]
[color=#000000]The crashes happens undeterministically. Sometimes it runs for up to 3000 log lines and literally one run later i crashes after log line 400 or so....and from quick checks up to this everything is ok/identical. So it must have something to do with address layout ,which is different each run (i guess partly due to ASLR).[/color][/color]
[color=#000000]
[color=#000000]My biggest problem, since each crash is different, i cannot set proper breakpoints beforehand - and after the crash i do not have much insights what happened.[/color][/color]
[color=#000000]
[color=#000000]I assume i need to write out much more logs/traces...any idea which would be helpful?[/color][/color]
After Microsoft released the remote debug tools for ARM64 i went back to debug my issue.
I am happy to report that i have found the issue:
In JitArm64_BackPatch.cpp
Code:
m_fault_to_handler.erase(slow_handler_iter);
emitter.FlushIcache();
ctx->CTX_PC = (u64)slow_handler_iter->first;
Rootcause:
slow_handler_iter->first is accessed after element has been removed from the std::map.
Issue was that PC got randomly (rarely) a wrong value and crashed after return from exception.
After doing the erase operation after updating the context JitARM64 is working now for Windows!
*cheers*
Nice. Do you want to open a PR for this bug? I've already dropped the plattform register, so upstream should be close to working already.
Edit: You should rebase your branch. This bug has been fixed a month ago:
https://github.com/dolphin-emu/dolphin/pull/7033
(07-16-2018, 05:20 PM)degasus Wrote: [ -> ]Nice. Do you want to open a PR for this bug? I've already dropped the plattform register, so upstream should be close to working already.
Edit: You should rebase your branch. This bug has been fixed a month ago: https://github.com/dolphin-emu/dolphin/pull/7033
Thanks for the hint! This fix must have gone into the code shortly after I decided to wait for remote debugging support...
Positive things first. ARM64 version is running great and stable under Windows with Snapdragon 835 SoC using Direct3D/XInput/XAudio2.
Getting 60 fps with 2x native resolution in quite a few games like: Soul Calibur 2, Burnout, Viewtiful Joe, Rayman 3. RE4 is also running fullspeed @30 fps - all with perfect sound.
As comparison Viewtiful Joe was running with 16 fps with cached interpreter before
Did a pull a and merge...now for some reason WxWidgets is removed from externals - likewise the main project is now Dolphin_QT
Does this mean I need to get hold of QT framework and compile this externally?
(07-17-2018, 08:42 AM)Helios Wrote: [ -> ]Yes.
Hi all,
after the move to QT I stopped working on this as i had bigger issues compiling QT and was running out of spare time. However since i had some spare time recently i was working on QT again and i have it now compiled for ARM64.
In addition i grabbed the latest Dolphin sources and it compiled without any issues - seems like all issues i had last year are gone by now. It runs fine as well - tested on HP ENVY X2 and Surface Pro X.
Can anyone help me with upstreaming the changes? It is mostly Visual Studio project file related with only a few (like 10) of source files changed. Ideally i would like to just zip the changes without going via public repo and pull-request but if thats not possible i will be trying to go the public repo path.
Gerdya
(12-02-2019, 12:24 AM)MayImilae Wrote: [ -> ]Things are a little different now: https://github.com/dolphin-emu/dolphin/pull/8495
Not so cool. Seems someone already pushed some ARM64 changes to the project files like 5 days ago - while apparently also upgrading platform toolset and compiler to VS2019. This pretty much mean my commits would be conflicting.
So an ARM64 build of dolphin is in development right now? That's awesome! Will be great for future ARM users.