This is time based block profiling unlike the ARMv7 core.
I would like to add cycle counter based block profiling like the ARMv7 core, but it first requires writing a kernel module to enable the counters to userland applications
This affects enabling and disabling block profiling on the fly.
The block profiling pauses the CPU cores and then flushes the JIT's block cache and enables block profile.
The issue with this is that when we pause the CPU core, we don't have a way to tell if the JIT recompiler has actually left.
So if the secondary thread that is clearing the JIT block cache is too quick, it will clear the cache as a recompiler is still running that block that
has been cleared.
Replaces them with forward declarations of used types, or removes them entirely if they aren't used at all. This also replaces certain Common headers with less inclusive ones (in terms of definitions they pull in).
This is available with the `GDBSocket` option in
`~/.dolphin-emu/Config/Dolphin.ini`.
GDB can connect to it with:
$ powerpc-eabi-gdb
(gdb) target remote |socat STDIO UNIX:foo.sock
Because I don't like so much binding the GDB stub socket to 0.0.0.0.
On Linux, with a suitable umask, we can make sure that another local
user cannot connect to the socket.
PowerPC does exceptions and hardware and stuff, Memory doesn't.
I did not realize until a few minutes ago that there were two versions of these functions. This is why namespaces suck. Anyway, these were added by Mullin earlier this year.
They weren't sufficient and are made redundant by previous commits; they
also (on master) caused breakage due to Jit64::psq_stXX assuming writes
would be fastmem and not clobber a register under certain conditions.
That really needs to be refactored, but for now, this works.
Change TMemCheck::Action to return whether to break rather than calling
PPCDebugInterface::BreakNow, as this simplified the implementation; then
remove said method, as that was its only caller. One "interface" method
down, many to go...
Without fastmem, the JIT code still does an inline check for RAM
addresses. With watchpoints we have to disable that too. (Hardware
watchpoints would avoid all the slow, but be complicated to implement
and limited in number - I doubt most people debugging games care much if
they run slower.)
With this change and watchpoints enabled, Melee runs at no more than 40%
speed, despite running at full speed without them. Oh well. Better
works slowly than doesn't bloody work.
Incidentally, I'm getting an unrelated crash in
PowerPC::HostIsRAMAddress when shutting down a game. This code sucks.
- Move JitState::memcheck to JitOptions because it's an option.
- Add JitOptions::fastmem; switch JIT code to checking that rather than
bFastmem directly.
- Add JitBase::UpdateMemoryOptions(), which sets both two JIT options
(replacing the duplicate lines in Jit64 and JitIL that set memcheck
from bMMU).
- (!) The ARM JITs both had some lines that checked js.memcheck
despite it being uninitialized in their cases. I've added
UpdateMemoryOptions to both. There is a chance this could make
something slower compared to the old behavior if the uninitialized
value happened to be nonzero... hdkr should check this.
- UpdateMemoryOptions forces jo.fastmem and jo.memcheck off and on,
respectively, if there are any watchpoints set.
- Also call that function from ClearCache.
- Have MemChecks call ClearCache when the {first,last} watchpoint is
{added,removed}.
Enabling jo.memcheck (bah, confusing names) is currently pointless
because hitting a watchpoint does not interrupt the basic block. That
will change in the next commit.
The regBuildMemAddress function already clears the address register.
Not only is clearing it again pointless, regBuildMemAddress uses the
bits in IInfo slightly diffrently and the second clear can clear
the wrong registers causing bugs if something else actually needs to
use those registers.
