Dolphin, the GameCube and Wii emulator - Forums

Apologies if this is in the wrong section.

First of all, the rest of this post is kind of irrelevant depending on the answer to this question:

Does the debugger (accessible via passing "/d" at the command line) use the recompiler core and/or have the ability to? I am guessing it doesn't because the emulator slows from ~700% speed to ~10% for a particular test case. Also I imagine there aren't a whole lot, if any, emulators that have debuggers that don't run with an interpreter core (it's just silly not to...maybe).

If it doesn't use the recompiler or have the ability to, I would like to add support for this. I don't want it to be sloppy either; I want to do a good job and come up with something clean for everyone to use, not just some hack only I would get any use from.

Unfortunately if I am going to do this I need more information about how the emulator does breakpoints to begin with and how I could feasibly get recompiled code to pass "messages" from the context of emulation to the debugging UI. I have figured some stuff out from poking around in the "Core" project of the solution (some of which is why I am not sure debugging can't be done with the dynarec, although I only saw a call to CCPU::Break() in the interpreter core) but I think it would go a lot faster (and the result would better conform to the project's standards) if I had someone more knowledgeable about the emulator's internal workings to give me some tips.

As for how insane the idea is, my logic is basically that the slowdown from adding extra instructions in with every recompiled load and store opcode for determining if there is a hit (which might not even have to be inlined) won't be enough to make debugging with the recompiler core less favorable to debugging with the interpreter core. Of course this doesn't address the real insanity: meta instructions embedded in recompiled code and having them report collisions, not to mention the difficulty in breaking on an exact instruction due to the code being recompiled and not interpreted. My plan was to go for an approximate breakpoint; it doesn't have to be exact to be useful, but I'd hate to have a modularity nightmare result. So once again, I think it'd be good to have an expert analysis of the idea.

Yes, the debugger can use the recompiler core or the interpreter core. It was implemented in r5833. Breakpoints have also been implemented in interpreter and jit modes.

The interesting function would probably be PowerPC::CheckBreakPoints(). Also check out the "blockSize = 1;" line in Jit.cpp

You'll notice that the debugger goes a bit faster in jit mode compared to the interpreter mode. For a bigger speed up (at the expense of breakpoint functionality), comment out the blockSize = 1 line.

I also have some uncommitted code for memory access breakpoints. The code breaks at the line after the read/write was performed. If you can work out how to break before the opcode is executed, I'd be very interested in seeing it.

Apologies if this question sounds dumb, but how can I tell which core it's using/pick which core it uses when using the debugger? I looked around and couldn't figure it out. Given the 70x emulation slow down I'm thinking it probably starts off with the interpreter core but then again memory accesses aren't all that uncommon. That said whatever was implemented in r5833 is probably more optimal than anything I was imagining so I have to wonder...

Also, did you post a patch of your uncommitted code? It might be a good starting point for me if I decide to fiddle toward your improvement idea.

In the options, under CPU emulation engine. The debugger is slow because we're checking for breakpoints at every PPC instruction. The code I have at the moment does not do much more than what has already been committed. For now, maybe look into PowerPC.cpp, Jit.cpp, and MemmapFunctions.cpp and generally familiarizing yourself with the Jit code.