This eliminates public usage of the GetMenuBar() function in CodeWindow.
The benefit of this is it also gets rid of the need to perform direct
access across the config dialog and the main frame. It also gets rid of
the use of the main_frame global.
GetMenuBar() will be removed entirely from CodeWindow in a follow-up that
also removes any related remnants of code made obsolete with its removal.
Gets rid of more menu-related code from CodeWindow and puts it back in
CFrame where it belongs.
This turns the previous menu update function within CodeWindow into one
that simply updates the debugger font for its managed controls. It also
improves how the font is actually updated. Previously, fonts would change,
however this wouldn't actually reflect onto the respective controls until
a refresh or update event occurred. Since codeview, callstack, symbols,
callers, and calls windows are all managed by a wxAuiManager instance,
calling Update() on it after the font has been set will reflect font
changes immediately.
This not only fixes a regression where toggling a breakpoint using the CodeWindow would cause a Center PC, but it also removes several redundant JumpToAddress(PC) calls.
Unifies the creation of all the menus into the main frame class.
Now it isn't spread out across the main frame and the code window.
This doesn't alter the placement of the handling functions, as this would
involve unrelated changes, since it would require modifying where
window-related variables are placed. This will be amended in a follow up
changeset.
This is done to remove confusions among potential debugger users and to also make it more accurately tell what this feature is actually doing. Despite being true that it is using a memcheck (and it certianly checks that memory), the idea being to break on a memory access isn't really obvious especially considering that memchecks are also used in full MMU emulation to handle exceptions. It also doesn't help that memchecks are now supported in every builds.
It also changes the corresponding log because this log would be wanted by the user which means it should be more obvious that it was caused by the "memory breakpoint".
Changes:
- MemoryWindow was cleaned up and gives more feedback on searches.
Some bugs were fixed as well:
- A complex bug that allowed tearing off tabs and opening multiple
copies of a debug panel which lead to segfaults
- Another segfault related to right-click menus on code/memory views
when those tools were floating in their own window.
There was a bug that caused MemoryView to indirectly cause a segfault;
the simplest way to reproduce it is 1) start a game; 2) stop the game;
3) click on the Refresh button and watch Dolphin segfault.
This commit fixes it by only calling PowerPC::HostIsRAMAddress when
emulation is running.
Considering there's a public method in the class using it, leaving the
definition in the cpp file can cause a linker error if any method outside
that cpp file calls it for one reason or another.
Single step: Fix an oddity when a breakpoint is hit at the beginning of a block, then after, a single step is performed and finally, hitting play, the breakpoint will be skipped even in the case when it would be hit again. This was done by using the interpreter version of single step. Also, remove some redundant update request.
Step over: fix some GUI lags.
Step out: Add consideration for conditional branching by checking the condition as the interpreter does. Now, every bclr instructions except those that changes the LR (because it would not be the end of the function) will cause the end of the step out and not just blr instructions. Also now stops if a bp is detected and finally, remove redundant GUI updates calls.
This also removes a superfluous draw call on the GUI as the codeView was refreshing twice per event to do so.
The old one wasn't very optimal because not only the user would likely want to enter an address instead of a range, but it also made entering just one address confusing (you had to have the same value on both start and end). Also, you should only chose one option between read, write or both, there is no point to not have any.
This is why I made more clear how to add an address and it is the default option using radio buttons and I also made the action flags and the flags to be radio buttons.
There might be a better way to highlight the options when adding the memory check, but for now, this works and the breakpoint list reports the right settings anyway.
It wouldn't impact performance until at least one memcheck is enabled. Because of this, it can be used in release builds without much impact, the only thing that woudl change is the use of HasAny method instead of preprocessor conditionals. Since the perforamnce decrease comes right when the first memcheck is added and restored when the last is removed, it basically is all beneficial and works the same way.
All formatting are individual per registers and they all have one option to go back to their original hexadecimal form.
- GPR: signed integer, unsigned integer, float
- FPR: double
Also happened to come accross an issue where editing the PFR would ignore the higher 32 bits of the new value, this had to be fixed for the format to work.
This removes a Dolphin-specific patch to the wxWidgets3 code
for the following reasons:
* Calling wxWindowGTK::DoSetSize on a top-level window can end up
calling wxTopLevelWindowGTK::DoMoveWindow, which triggers an assert
because it is not supposed to be called for a top-level wxWindow.
* We should not be patching the wxWidgets code because that means the
toolbars will still be broken if someone builds without using the
WX that is in our Externals.
Instead, we now use a derived class for wxAuiToolBar and override
DoSetSize() to remove the problematic behaviour to get the same effect
(fixing toolbars) but without changing Externals code and without
causing asserts and other issues.
For step over, it was updating twice which actually made the red display on the register view (when a register changes since) malfunction. Since it doesn't seem to be usefull to update before AND after the run, the one before the run was removed.
For step out, well, because there was no chances given for the thread to run as it is single stepping all the time, I only added a call to update after it was done.
Lioncash