You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opcode for a bkpt 0 ARM instruction: 0xE1200070 (little endian bytes: 70 00 20 E1)
Opcode for a bkpt 0 Thumb instruction: 0xBE00 (little endian bytes: 00 BE)
Currently, GDBStub::CommitBreakpoint hardcodes the ARM opcode in so that the JIT/Dynarmic gets simple breakpoint support through the CPU exception handler. However, one can't expect GDBStub to guess if the target code is in ARM-mode or Thumb-mode: if guessed wrong, then it'll corrupt the code and cause unexpected behaviour. (We could look for odd addresses ending in 2, 6, A, or E, but this would merely be a hack / an edge case.)
Fortunately, as long as not more than 1 instruction is corrupted, DynCom / interpreter wouldn't care anyway, as it uses GDBStub::GetNextBreakpointFromAddress after each dispatch to predict when it's about to hit a breakpoint.
Idea: move the logic of installing a bkpt 0 opcode out of CommitBreakpoint and RemoveBreakpoint, and into the JIT somehow.
The text was updated successfully, but these errors were encountered:
DimitriPilot3
changed the title
gdbstub: Only ARM breakpoints are supported, not Thumb
gdbstub: Dynarmic only supports ARM breakpoints, not Thumb
Jan 31, 2019
Opcode for a
bkpt 0
ARM instruction:0xE1200070
(little endian bytes: 70 00 20 E1)Opcode for a
bkpt 0
Thumb instruction:0xBE00
(little endian bytes: 00 BE)Currently, GDBStub::CommitBreakpoint hardcodes the ARM opcode in so that the JIT/Dynarmic gets simple breakpoint support through the CPU exception handler. However, one can't expect GDBStub to guess if the target code is in ARM-mode or Thumb-mode: if guessed wrong, then it'll corrupt the code and cause unexpected behaviour. (We could look for odd addresses ending in 2, 6, A, or E, but this would merely be a hack / an edge case.)
Fortunately, as long as not more than 1 instruction is corrupted, DynCom / interpreter wouldn't care anyway, as it uses
GDBStub::GetNextBreakpointFromAddress
after each dispatch to predict when it's about to hit a breakpoint.Idea: move the logic of installing a
bkpt 0
opcode out of CommitBreakpoint and RemoveBreakpoint, and into the JIT somehow.The text was updated successfully, but these errors were encountered: