Debugger: Add conditional data breakpoints, and a few minor bug fixes #2473
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mateusfavarin
changed the title
|
Thanks! I'll get around to reviewing this soon, super busy with work this week :( |
stenzek
reviewed
Aug 7, 2021
src/core/cpu_core.cpp
Outdated
| { | ||
| const u32 pc = g_state.regs.pc; | ||
| Instruction inst = g_state.current_instruction; | ||
| inst.bits = inst_bits; |
| if (inst.bits == 0) | ||
| return false; | ||
|
|
||
| switch (inst.op) |
There was a problem hiding this comment.
Just read g_state.current_instruction
src/core/cpu_core.cpp
Outdated
| // continue is measurably faster than break on msvc for some reason | ||
| continue; | ||
| } | ||
| if (ExecutionBreakpointCheck()) |
There was a problem hiding this comment.
if (ExecutionBreakpointCheck() || ConditionalBreakpointLookAhead())
src/core/cpu_core.cpp
Outdated
| case InstructionOp::lw: | ||
| { | ||
| const VirtualMemoryAddress addr = ReadReg(inst.i.rs) + inst.i.imm_sext32(); | ||
| DataBreakpointCheck<MemoryAccessType::Read>(addr); |
There was a problem hiding this comment.
This is going to get very slow. It would probably be better to align the test address down, and do a single range check in DataBreakpointCheck.
| @@ -17,6 +17,21 @@ enum class MemoryAccessSize : u32 | |||
| Word | |||
| }; | |||
|
|
|||
| struct DebugAddress | |||
There was a problem hiding this comment.
Rather than combining the breakpoints, it'd be better to store the execution and data breakpoints in separate arrays (fewer loops/comparisons for every guest instruction).
stenzek
force-pushed
the
master
branch
3 times, most recently
from
f4c48a2
to
0ef2439
Compare
stenzek
force-pushed
the
master
branch
3 times, most recently
from
dbbf234
to
e3d9ba4
Compare
stenzek
force-pushed
the
master
branch
3 times, most recently
from
5bb1e94
to
f993f09
Compare
stenzek
force-pushed
the
master
branch
3 times, most recently
from
8fb8259
to
5ef2ba0
Compare
stenzek
force-pushed
the
master
branch
2 times, most recently
from
1f89203
to
084a76a
Compare
stenzek
force-pushed
the
master
branch
6 times, most recently
from
2005150
to
8867bb1
Compare
stenzek
force-pushed
the
master
branch
2 times, most recently
from
b26a4d7
to
7ea7d3b
Compare
stenzek
force-pushed
the
master
branch
4 times, most recently
from
349fcfa
to
6d3f01c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've implemented conditional data breakpoints for variable memory sizes. Duckstation was storing the address of each breakpoint as the information to check for when an execution breakpoint is valid. I expanded this idea by creating the struct
DebugAddress, which encapsulates anaddress, asizeand adebug_mode. The user can create aDebugAddressby adding a breakpoint using the UI, and select multiple conditions for the breakpoint: read, write, changed value or execution.The execution breakpoint that was implemented on duck had to be modified by adding an extra check for the
debug_mode, so only execution breakpoints can trigger that event. The data breakpoint was implemented by adding a function that looks ahead of what the next CPU instruction is going to be, and if the next instruction matches the conditions of anyDebugAddress, then the emulation is paused before the CPU executes that instruction. The UI had to be changed in order for the user to create such breakpoints.A few minor bug fixes unrelated to that:
sll zero, zerotonop.This PR addresses some of the issues mentioned at #2179.