Login

Abystus · 08-03-2014, 07:21 AM

I have encountered a few issues with the debugger, and assume this is the place to report it. A list of what I have experienced is below:

Issues:

Code:
- "Assemble Opcode" is grayed out (is this implemented?).

- "Step Out" is always grayed out (is this implemented?).

- Changing instruction values in memory will result in a crash (most of the time), and happens when attempting to modify any part of the instruction during a breakpoint.  This is not dependant on if it is the current instruction executing or not.  It may stem from the recompiler block as a whole executing, and not the single instruction.  I have not attempted this in interpreter mode due to how slow the emulation is.

- I am currently unable to get any instructions logging to "emuLog.txt".  It seems to log only a reflection of what is happening in the log window (emulator state changes, normal output), and not actual instructions being executed within the emulator core (have this checked for logging only) up to or past a breakpoint.  Is there no way to get the actual assembly (as shown in the disassembler) logging straight to a file?

Trace Logging Setup:

[Image: VP4PAVv.png]

Error Changing Instruction in Memory:

[Image: JBbFZco.png]

Code:
..\..\System\SysThreadBase.cpp(149) : assertion failed:

    Function:  SysThreadBase::Pause

    Thread:    Main/UI

    Condition: m_ExecMode == ExecMode_Pausing

    Message:   ExecMode should be nothing other than Pausing...

Stacktrace:

[00] 0x0163564A                                  

[01] 0x0109C46C                                  

[02] 0x00F75F6E                                  

[03] 0x01030256                                  

[04] 0x013298B6                                  

[05] 0x0132A402                                  

[06] 0x01404053                                  

[07] 0x01403BE6                                  

[08] 0x01403F2E                                  

[09] 0x014BC105                                  

[10] 0x014C240F                                  

[11] 0x014C8D6B                                  

[12] CallNextHookEx                              

[13] CallNextHookEx                              

[14] GetMessageW                                 

[15] IsDialogMessageW                            

[16] 0x014C14A2                                  

[17] 0x01581DC1                                  

[18] 0x01581E32                                  

[19] 0x01581737                                  

[20] 0x0154359C                                  

[21] 0x01545BA5                                  

[22] 0x01640FAC                                  

[23] 0x0165783D                                  

[24] 0x01657AEB                                  

[25] 0x01666689                                  

[26] 0x01346363                                  

[27] 0x0130A5F6                                  

[28] 0x01308E96                                  

[29] 0x0131F100                                  

[30] 0x0131ED98                                  

[31] 0x01320436                                  

[32] 0x0149BF9F                                  

[33] NLG_Return                                  

[34] 0x01494FB0                                  

[35] 0x01547EE2                                  

[36] 0x0132DAD8                                  

[37] 0x0168785F                                  

[38] 0x0168761D                                  

[39] BaseThreadInitThunk                         

[40] RtlInitializeExceptionChain                 

[41] RtlInitializeExceptionChain

My Specs:

Code:
Windows 8.1

Intel i7 2600k

8gb DDR3

Geforce GTX 760

**pseudonym** · 08-03-2014, 06:14 PM

All memory writing is kinda broken until the writes happen on the core thread. The disasm log is for the interpreter and predates the debugger.

Kingcom · 08-03-2014, 06:16 PM

Assemble opcode isn't implemented yet, but there's an open pull request to add that feature. Step out isn't implemented yet at all.
Writing to memory that is part of a recompiler block leads to exceptions. The workaround for now is to force it to clear the cache, which happens when you toggle a breakpoint.

**gregory** · 08-03-2014, 06:56 PM

logging work but it need to be hand tuned a bits. Otherwise it is not usable.

You can easily get the log macro at the end of this file pcsx2/DebugTools/Debug.h.
In your case your use this one: #define CPU_LOG macTrace(EE.R5900)

As you can see CPU_LOG is only called when an instruction is not supported. You can edit the interpreter to print the instruction.

Code:
pcsx2/VUops.cpp-

pcsx2/VUops.cpp-void VU0unknown() {

pcsx2/VUops.cpp-    pxFailDev("Unknown VU micromode opcode called");

pcsx2/VUops.cpp:    CPU_LOG("Unknown VU micromode opcode called");

pcsx2/VUops.cpp-}

pcsx2/VUops.cpp-

pcsx2/VUops.cpp-static void __vuRegsCall VU0regsunknown(_VURegsNum *VUregsn) {

pcsx2/VUops.cpp-    pxFailDev("Unknown VU micromode opcode called");

pcsx2/VUops.cpp:    CPU_LOG("Unknown VU micromode opcode called");

pcsx2/VUops.cpp-}

pcsx2/VUops.cpp-

pcsx2/VUops.cpp-// --------------------------------------------------------------------------------------

--

pcsx2/VUops.cpp-

pcsx2/VUops.cpp-static void VU1unknown() {

pcsx2/VUops.cpp-    pxFailDev("Unknown VU micromode opcode called");

pcsx2/VUops.cpp:    CPU_LOG("Unknown VU micromode opcode called");

pcsx2/VUops.cpp-}

pcsx2/VUops.cpp-

pcsx2/VUops.cpp-static void __vuRegsCall VU1regsunknown(_VURegsNum *VUregsn) {

pcsx2/VUops.cpp-    pxFailDev("Unknown VU micromode opcode called");

pcsx2/VUops.cpp:    CPU_LOG("Unknown VU micromode opcode called");

pcsx2/VUops.cpp-}

pcsx2/VUops.cpp-

pcsx2/VUops.cpp-

--

pcsx2/VU0.cpp-

pcsx2/VU0.cpp-void COP2_Unknown()

pcsx2/VU0.cpp-{

pcsx2/VU0.cpp:    CPU_LOG("Unknown COP2 opcode called");

pcsx2/VU0.cpp-}

pcsx2/VU0.cpp-

pcsx2/VU0.cpp-//****************************************************************************

--

pcsx2/R5900OpcodeImpl.cpp-}

pcsx2/R5900OpcodeImpl.cpp-

pcsx2/R5900OpcodeImpl.cpp-void Unknown() {

pcsx2/R5900OpcodeImpl.cpp:    CPU_LOG("%8.8lx: Unknown opcode called", cpuRegs.pc);

pcsx2/R5900OpcodeImpl.cpp-}

pcsx2/R5900OpcodeImpl.cpp-

pcsx2/R5900OpcodeImpl.cpp-void MMI_Unknown() { Console.Warning("Unknown MMI opcode called"); }

--

pcsx2/DebugTools/Debug.h-#define SIF_LOG            macTrace(SIF)

pcsx2/DebugTools/Debug.h-

pcsx2/DebugTools/Debug.h-#define BIOS_LOG        macTrace(EE.Bios)

pcsx2/DebugTools/Debug.h:#define CPU_LOG            macTrace(EE.R5900)

pcsx2/DebugTools/Debug.h-#define COP0_LOG        macTrace(EE.COP0)

pcsx2/DebugTools/Debug.h-#define VUM_LOG            macTrace(EE.COP2)

pcsx2/DebugTools/Debug.h-#define MEM_LOG            macTrace(EE.Memory)

--

pcsx2/Interpreter.cpp-    // Another method of instruction dumping:

pcsx2/Interpreter.cpp-    /*if( cpuRegs.cycle > 0x4f24d714 )

pcsx2/Interpreter.cpp-    {

pcsx2/Interpreter.cpp:        //CPU_LOG( "%s", disR5900Current.getCString());

pcsx2/Interpreter.cpp-        disOut.clear();

pcsx2/Interpreter.cpp-        opcode.disasm( disOut );

pcsx2/Interpreter.cpp-        disOut += '\n';

pcsx2/Interpreter.cpp:        CPU_LOG( disOut.c_str() );

pcsx2/Interpreter.cpp-    }*/

pcsx2/Interpreter.cpp-

pcsx2/Interpreter.cpp-

For example somethings like that

Code:
    if (cpuRegs.pc == 0x8900363c) {

        runs = 0;

    }

    if (runs < 10000) {

        //Console.WriteLn("PC:%x DATA:%x", cpuRegs.pc, memRead32(cpuRegs.pc));

        disOut.clear();

        opcode.disasm( disOut );

        disOut += '\n';

        CPU_LOG( disOut.c_str() );

    }

Note: the memory log only show the bad memory access not the correct memory access.

Abystus · (This post was last modified: 08-04-2014, 06:31 PM by Abystus.)

(08-03-2014, 06:14 PM)pseudonym Wrote: All memory writing is kinda broken until the writes happen on the core thread. The disasm log is for the interpreter and predates the debugger.

I do hope to see these issues ironed out eventually, along with instruction logging for the recompiler core as well.

(08-03-2014, 06:16 PM)Kingcom Wrote: Assemble opcode isn't implemented yet, but there's an open pull request to add that feature. Step out isn't implemented yet at all.
Writing to memory that is part of a recompiler block leads to exceptions. The workaround for now is to force it to clear the cache, which happens when you toggle a breakpoint.

"Assemble Opcode" would be a great feature to have as I would not have to directly modify the memory to implement changes to the instructions. I will try the breakpoint toggle trick method you speak of, and hopefully it resolves the crashes for now (If I can remember to do it before each modification I make). Thanks for the tip, and I hope to see this feature along with "Step Out" (fairly easy to code) implemented soon.

(08-03-2014, 06:56 PM)gregory Wrote: logging work but it need to be hand tuned a bits. Otherwise it is not usable.

You can easily get the log macro at the end of this file pcsx2/DebugTools/Debug.h.
...

Thanks for the info. Maybe someone can step up and implement this feature the proper way Smile

.

Login
Username:
Password:	Lost Password?
	Remember me