summaryrefslogtreecommitdiff
path: root/arch/arm64/tools
diff options
context:
space:
mode:
authorKristina Martsenko <kristina.martsenko@arm.com>2023-05-09 17:22:32 +0300
committerCatalin Marinas <catalin.marinas@arm.com>2023-06-05 19:05:41 +0300
commit8cd076a67dc8eac5d613b3258f656efa7a54412e (patch)
treecf8d856b6433c36d1ffd8b466b429f001091b0ac /arch/arm64/tools
parent8536ceaa747174ded7983f13906b225e0c33ac51 (diff)
downloadlinux-8cd076a67dc8eac5d613b3258f656efa7a54412e.tar.xz
arm64: mops: handle single stepping after MOPS exception
When a MOPS main or epilogue instruction is being executed, the task may get scheduled on a different CPU and restart execution from the prologue instruction. If the main or epilogue instruction is being single stepped then it makes sense to finish the step and take the step exception before starting to execute the next (prologue) instruction. So fast-forward the single step state machine when taking a MOPS exception. This means that if a main or epilogue instruction is single stepped with ptrace, the debugger will sometimes observe the PC moving back to the prologue instruction. (As already mentioned, this should be rare as it only happens when the task is scheduled to another CPU during the step.) This also ensures that perf breakpoints count prologue instructions consistently (i.e. every time they are executed), rather than skipping them when there also happens to be a breakpoint on a main or epilogue instruction. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> Link: https://lore.kernel.org/r/20230509142235.3284028-9-kristina.martsenko@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Diffstat (limited to 'arch/arm64/tools')
0 files changed, 0 insertions, 0 deletions