starred/Mu
1
0
Fork 0
mirror of https://github.com/libretro/Mu.git synced 2026-09-24 07:35:55 +00:00
Code Issues 18 Packages Projects Releases 2 Wiki Activity

Fix consistncy of REG_PPC, it is now always the start address of the last opcode executed

Browse Source 
Before there was an inconsistancy where it would be set to the current opcode when exiting the loop, that causes weird side effects and is completely unneeded since it will just be set the next time the loop starts anyway.
This commit is contained in:
meepingsnesroms
2019-04-14 22:36:20 -07:00
parent 4c27b1abb1
commit efc3b9ca77
3 changed files with 8 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
qtBuildSystem/Mu/Mu.pro
View File

@@ -65,7 +65,7 @@ CONFIG(debug, debug|release){
# DEFINES += EMU_SANDBOX_LOG_MEMORY_ACCESSES # checks all reads and writes to memory and logs certain events
DEFINES += EMU_SANDBOX_OPCODE_LEVEL_DEBUG # for breakpoints
DEFINES += EMU_SANDBOX_LOG_JUMPS # log large jumps
# DEFINES += EMU_SANDBOX_LOG_APIS # for printing sysTrap* calls, EMU_SANDBOX_OPCODE_LEVEL_DEBUG must be on too
DEFINES += EMU_SANDBOX_LOG_APIS # for printing sysTrap* calls, EMU_SANDBOX_OPCODE_LEVEL_DEBUG must be on too
macx|linux-g++{
# also check for any buffer overflows and memory leaks
# -fsanitize=undefined,leak

10
src/debug/sandbox.c
View File

@@ -199,7 +199,7 @@ void log68kJumps(void){
static void logApiCalls(void){
uint32_t programCounter = m68k_get_reg(NULL, M68K_REG_PPC);
uint16_t instruction = m68k_get_reg(NULL, M68K_REG_IR);
uint16_t instruction = m68k_read_memory_16(programCounter);
if(instruction == 0x4E4F/*Trap F/API call opcode*/){
uint16_t trap = m68k_read_memory_16(programCounter + 2);
@@ -814,7 +814,7 @@ void sandboxReset(void){
//sandboxCommand(SANDBOX_CMD_REGISTER_WATCH_ENABLE, NULL);
//monitor for strange jumps
sandboxSetWatchRegion(0x00000000, 0xFFFFFFFE, SANDBOX_WATCH_CODE);
//sandboxSetWatchRegion(0x00000000, 0xFFFFFFFE, SANDBOX_WATCH_CODE);
}
uint32_t sandboxStateSize(void){
@@ -1046,7 +1046,7 @@ uint32_t sandboxCommand(uint32_t command, void* data){
ROM:10021C8C addq.l #1,d5 ; 16 bit align ???
*/
//size extra bits are not being set when chuncks are allocated
//size extra bits are not being set when chunks are allocated
//PrvChunkNew derives size extra from total size - requested size, so its already safe, PrvPtrResize does the same
/*
@@ -1059,6 +1059,10 @@ uint32_t sandboxCommand(uint32_t command, void* data){
ROM:1002100A or.b d0,(a2) ; Inclusive-OR Logical
*/
//PrvPtrResize is likely moving the chunk in front forwards if its small enough and leaving the data in place to save the opcodes needed to copy the data elsewhere
//if this is true then a resize of existing size + 2 will push the next chunk forward by 2 misaligning it
//could also be moving the header backwards by 2 if its willing to shift all the data manualy or corrupt the data
//patch PrvChunkNew to 32 bit alignment, this alone does not fix 32 bit alignment issues
patchOsRom(0x20D04, "202E000AC0BCFFFFFFFCB0AE000A6700000458805080544F");//adds an extra 4 bytes if & 0x00000003 is true
//when moving memory around some 16 bit aligned pointers still show up

3
src/m68k/m68kcpu.c
View File

@@ -677,9 +677,6 @@ int32_t m68k_execute(int32_t num_cycles)
m68ki_exception_if_trace(); /* auto-disable (see m68kcpu.h) */
} while(GET_CYCLES() > 0);
/* set previous PC to current PC for the next entry into the loop */
REG_PPC = REG_PC;
/* ASG: update cycles */
USE_CYCLES(CPU_INT_CYCLES);
CPU_INT_CYCLES = 0;