Commit Message

A BookE branch taken debug exception followed by a single step does not
accurately simulate Server's branch execute debug exception. BookE's
branch taken debug exception stops before the branch is to be executed
and only happens if the branch will actually be taken. Server's branch
execute trace exception stops on the instruction after the branch
executes, regardless of whether or not the branch redirected the program
counter.
The existing PTRACE_SINGLEBLOCK support for BookE hardcodes a single
step after the branch taken exception is taken in order to simulate
Server's behavior, but this misses fall-through branch instructions
(i.e., branches that are NOT taken). Also, the si_code became masked as
TRAP_TRACE instead of TRAP_BRANCH.
This patch makes available the unmodified BookE branch taken debug
exception through PTRACE_SINGLEBLOCK if the ptrace() addr parameter is
set to 2. (The existing behavior of PTRACE_SINGLEBLOCK is retained for
any other addr parameter value, e.g., 0.) SIGTRAP will be signaled with
the NIP pointing to the branch instruction before it has executed. The
ptrace-calling program can then examine the program state. It should
then request a PTRACE_SINGLESTEP in order to advance the program to the
next instruction or a PTRACE_CONT to resume normal program execution.
The si_code now also reports TRAP_BRANCH.
Signed-off-by: James Yang <James.Yang@freescale.com>
---
arch/powerpc/include/asm/thread_info.h | 3 ++
arch/powerpc/kernel/traps.c | 51 ++++++++++++++++++++++++-------
kernel/ptrace.c | 13 ++++++--
3 files changed, 52 insertions(+), 15 deletions(-)

Comments

On 07/05/2013 05:11:04 PM, James Yang wrote:
> This patch makes available the unmodified BookE branch taken debug> exception through PTRACE_SINGLEBLOCK if the ptrace() addr parameter is> set to 2.
This is hacky -- if we must retain the existing PTRACE_SINGLEBLOCK
semantics (which aren't actually documented anywhere AFAICT -- if the
details are meant to be implementation-defined, then don't we have some
freedom here to actually do what the hardware does, especially if we
can't find existing users?), then perhaps a new PTRACE_WHATEVER should
be defined.
At the very least, magic numbers should be given symbolic names.
-Scott