Patchwork [RFC/PATCH] powerpc: Add PTRACE_SINGLEBLOCK support

From: Roland McGrath <roland@redhat.com>

Reworked by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

This adds block-step support on powerpc, including a PTRACE_SINGLEBLOCK
request for ptrace.

The BookE implementation is tweaked to fire a single step after a
block step in order to mimmic the server behaviour.

Signed-off-by: Roland McGrath <roland@redhat.com>
---

WARNING: There is a difference between the BookE implementations
(that use DBCR0:BT) and the "classic" implementations (that use MSR:BE).

The former will stop -on- the branch that is about to be taken without
actually taking it, while the later will stop on the -target- of the
branch.

The BookE variant is superior in some ways as it allows to know where
you come from on branches. But that also means that the semantics exposed
to user space would not be consistent which is BAD (tm).

I'm not sure what the right approach is. For now, I've made BookE mimmic
server by automatically firing a single step right after the blockstep
from the kernel, so the semantics exposed to userspace are identical,
but that mean we do lose some information in the BookE case that would
have otherwise been available (the branch origin).

Now, some server processors do provide it via an SPR, but I don't know
if we can retrieve it, because I think it could be clobbered by the act
of taking the debug interrupt ... non trivial.

Roland, what do you think is the right approach ? This patch ?

 arch/powerpc/include/asm/ptrace.h |    4 ++++
 arch/powerpc/kernel/head_booke.h  |   10 +++++-----
 arch/powerpc/kernel/ptrace.c      |   23 +++++++++++++++++++++--
 arch/powerpc/kernel/traps.c       |   34 ++++++++++++++++++++++++++++++----
 4 files changed, 60 insertions(+), 11 deletions(-)

> The BookE variant is superior in some ways as it allows to know where
> you come from on branches. But that also means that the semantics exposed
> to user space would not be consistent which is BAD (tm).

If it were me I would start with a simpler patch that doesn't implement it
at all on BookE, and arch_has_block_step() yields 0 on those configs.
Later on when someone using BookE asks for it, revisit the complexity.
But that doesn't mean you shouldn't just go with what you've done now.

The reality is that there is no user expectation established one way or
another yet.  For a long time only ia64 had PTRACE_SINGLEBLOCK and for not
too many kernel versions has x86 had it too.  There aren't yet other
established uses of user_enable_block_step() so as to have an expectation
of what the semantics are.

arch_has_block_step() by itself does not indicate the details.  If there
is something more generic that starts to use this and thus cares to know
exactly what "block step" means, then we can figure it out.  My first
inclination is to have arch code provide only what is most natural and
simple on the given CPU and just have more-specific arch macros/inlines
saying what the behavior is (before branch or after branch, and whether
also before non-taken branches, are the only two bits of variance I can
think of).  Then whatever generic thing is built on this can test those
and cope.  i.e., a non-arch layer would be responsible for deciding that
doing an immediate single-step was the useful thing to do for this CPU's
flavor of block-step.

But I don't feel at all strongly that you shouldn't just roll it into
the arch code as you have done.  It's up to you--and really it's just
pending this getting exercised for any real-world purpose to see what
one really wants.  (Chances are such things would get done on x86 first,
where they might take advantage of several flavors of branch
source/target recording features.  So seeing what of all that some
actual tool used in practice might inform one's looking into what
analogues or subsets powerpc chips have to offer.)


Thanks,
Roland

On Fri, 2009-05-29 at 00:53 -0700, Roland McGrath wrote:
> > The BookE variant is superior in some ways as it allows to know where
> > you come from on branches. But that also means that the semantics exposed
> > to user space would not be consistent which is BAD (tm).
> 
> If it were me I would start with a simpler patch that doesn't implement it
> at all on BookE, and arch_has_block_step() yields 0 on those configs.
> Later on when someone using BookE asks for it, revisit the complexity.
> But that doesn't mean you shouldn't just go with what you've done now.

Well, the trick to do an additional single step on BookE to mimmic
server is about 3 lines of code :-) And it seems to work just fine, we
wrote a small test app that forks and the parent blocksteps the children
which does a few useless things we put in there, we get the same results
on server and 440.

So I wouldn't bother -removing- it

> The reality is that there is no user expectation established one way or
> another yet.  For a long time only ia64 had PTRACE_SINGLEBLOCK and for not
> too many kernel versions has x86 had it too.  There aren't yet other
> established uses of user_enable_block_step() so as to have an expectation
> of what the semantics are.

Allright, but it would suck for it to have different semantics on
powerpc depending on the processor you're on. So I think we need
to settle on one semantic for powerpc, and if we want to make the
BookE special one available to userspace, we can do so via a
different call.

> arch_has_block_step() by itself does not indicate the details.  If there
> is something more generic that starts to use this and thus cares to know
> exactly what "block step" means, then we can figure it out.  My first
> inclination is to have arch code provide only what is most natural and
> simple on the given CPU and just have more-specific arch macros/inlines
> saying what the behavior is (before branch or after branch, and whether
> also before non-taken branches, are the only two bits of variance I can
> think of).  Then whatever generic thing is built on this can test those
> and cope.  i.e., a non-arch layer would be responsible for deciding that
> doing an immediate single-step was the useful thing to do for this CPU's
> flavor of block-step.

I agree to some extent but I dislike if the call behaves differently
within a single arch. Don't you agree ?

For example, BookE doesn't have a DABR for data breakpoint, it has
another facility (DACs). However, we do "emulate" the DABR using one
of the DACs to provide that consistency.

Now we do have WIP patches to add more advanced BookE features (direct
access to the DACs, IACs and DVCs (data compare on watchpoints) etc...)
and so at some point we'll provide those more advanced APIs, I suppose
we can roll the BookE "specific" variant of blockstep in there too,
and keep the base API provide server-like semantics that are identical
on BookE and server.

> But I don't feel at all strongly that you shouldn't just roll it into
> the arch code as you have done.  It's up to you--and really it's just
> pending this getting exercised for any real-world purpose to see what
> one really wants.  (Chances are such things would get done on x86 first,
> where they might take advantage of several flavors of branch
> source/target recording features.  So seeing what of all that some
> actual tool used in practice might inform one's looking into what
> analogues or subsets powerpc chips have to offer.)

Ok. I think I'll go with that patch then for now. I'll also look at the
WIP stuff for advanced BookE support and see if we can fold the BookE
variant of blockstep in there too for userspace that cares about it.

Cheers,
Ben.

> 
> Thanks,
> Roland