[Debugger] Memory View search box improvements #13470
Conversation
|
How much overlap does this have with cheat search? Other than not being able to set a BP from cheat search, it seems to allow the same thing without spamming a button. I don't use this technique, so I could be wrong. We can add a way to turn a selection in cheat search into memory BPs, if everything else is fine. |
The workflow is very different and debugger related. For example I search for 0x41F00000, set a breakpoint on the first 20 instances. Run the game. Check which ones were hit or not. Check if the ones hit matter with debugger or not, delete everything. Rinse and repeat until found. The level of control and relatedness to the code matters. It would not be as useful to me in the cheat search, this is less about values changing but about tracking static values usage and location and impact. Alignment filter in search is very important too. |
|
I agree aligning search is important. I want to make sure you're giving cheat search a fair consideration and that auto-BPs isn't overly specific to your workflow. I popped a context item to make BPs into cheat search (this should probably have been in CS already), and this seems to do what you want. Cheat search works fine with handling static values, specific address ranges, and is organized by address. GIF
If it's still a No, I won't insist further. |
|
Yes I use the Cheat Search extensively and it could be used in some cases as you shown in the video. It is just a quality of life thing I am proposing, when you are in the memory viewer, less clicks, mouse movements, you can eyeball the surrounding variables, skip places in memory where the values don't make sense, etc. Both Cheat Search and Memory View are very useful even if they share common functionality, they do it in different ways. For example technically we could remove the search in Memory View and use the Cheat Search for all searches, that would work, it would just not be as convenient to use. |
|
Alright, adding it isn't a big deal, just making sure. Should the BP size obey the alignment option? Except for code of course. -- Though this seems a little difficult to add. Do we create the breakpoint in MemoryWidget and avoid MemoryView? Or add an optional size variable to ToggleBreakpoint? Or just expect people to use the correct alignment Display? |
| @@ -60,6 +60,7 @@ class MemoryWidget : public QDockWidget | |||
| void OnBPTypeChanged(); | |||
|
|
|||
| void OnSearchAddress(); | |||
| void OnBreakOnAll(); | |||
There was a problem hiding this comment.
Sorry yes code went into the branch. Good catch.
|
Removed all the code that was not necessary or duplicative. |
|
FifoCI detected that this change impacts graphical rendering. Here are the behavior differences detected by the system:
automated-fifoci-reporter |
|
Code looks good to me, if using the BP size derived from the display alignment makes sense, then I have nothing else. |
Helpful when trying to find all accessed instances of a value for example 0x41f00000 (30.0) in a game. Put 0x41f0000 in the search box, set alignment to 4, set auto bp memory and spam the search button. Then run the game and examine the code using those values to see if any is relevant. Similar use case for code with lis r0, 0x41f0 for example.