There are a couple things in this PR.
Fixes a bug where if we hit an invalid instruction we would infinite loop.
Fixes an issue where on AArch64 it would show invalid instructions for all NEON instructions.
This was due to asimd and crc being optional extensions and LLVM not enabling them by default.
So we have to specify a CPU which has the feature. LLVM 3.6 will let us select by features instead of CPUs, but we don't have a release of that quite
yet.
If we are on an architecture that has a known instruction size, we will continue onward after hitting the invalid instruction. If we don't have a
known instruction size like on x86, we will instead just dump the rest of the block.
Since the menus aren't actually assigned a parent, they would not be freed by wx. Plus, these should have initially been constructed on the stack in the first place.
Technically any time someone right-clicked the game list they would be leaking memory.
This will work for all of our platforms, x86, ARMv7, and AArch64.
Main issue with this is that LLVM's cmake files aren't correctly finding the LLVM install.
Not sure if this is Ubuntu's issue or not, it may just work on other operating systems.
We could potentially improve this, you can pass in a specific CPU in to the LLVM disassembler. This would probably affect latency times that are
reported by LLVM's disassembly? This needs to be further investigated later.
This code was an absolute mess. It had allocated an arbitrarily large string buffer to hold instructions that were disassembled.
Strip out all of the nasty raw C string manipulation and replaces it with ostringstream usage.
Fixes an issue where if you didn't have a JIT recompiler running then Dolphin would instantly crash if you tried comparing PPC to x86 code.
Changed the disassembly of the host side code from being inline to the function to instead being in a class, this will be required when I add support
for ARMv7 and AArch64 to this window.
Previously it did the opposite of what it was supposed to; when checked, it'd
turn block linking on, and when unchecked, it'd turn it off.
Also update JITIL's block linking disabling in debug mode to match the behavior
of the regular JIT.
These ID values would clash with the window parent IDs of all the actual debugger panes (they are in the 350 range as well).
For example, attempting to show and then close the memory window would cause an assertion, because it would attempt to destroy the text control for searching through memory, rather than destroying the actual parent window it's attached to.
These IDs are only used locally, so their value doesn't matter.
Ryan Houdek