BookE "branch taken" behavior vis-a-vis updating the NIP register

[pegasus]

I re-read the link you posted earlier and this time it made more sense to me.
The kind of questions which are coming into my mind were being discussed.

So, off I went and downloaded the latest version of
arch/powerpc/kernel/traps.c hoping to see those very changes in them.
However it didn't match one on one with what was written in that thread.
Ditto for the other files in your patch. Looks like your patch didn't make
it to upstream but it looks exactly like what I need here. So allow me to
discuss certain finer points of it, to make sure I understand what it does
correctly.

In that thread you say 
James Yang wrote
> BookE ISA's branch taken exception triggers before a branch that will be
> taken executes.  This allows software to examine the branch and the
> conditions under which it will be taken.  It also means software can tell
> where basic blocks end (at least the ones which are terminated by taken
> branches).  
*
> There are no architected registers that report the address of the branch
> instruction after it has executed.
*
My thoughts exactly! 

In the first patch's description, you say 
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.  (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.

 So requesting PTRACE_CONT has to happen inside the SIGTRAP signal handler
right? So as to advance the branch instruction (and since we are talking
BookE here, we are dead sure this branch will be taken). Now as for the
second patch, as far as I can see, implements the same functionality.
However it makes the change permanent and any tool which is used to the NIP
pointing to the branch target will be broken. 

Anyways, for me either of them will work. But I think the first patch makes
everyone happy by using the 'addr' field of ptrace. This also means I will
have to make my (broken) ptrace working which, it seems is not as easy
adding an enum field as you suggested. May be theres a check somewhere in
the actual ptrace code which checks for illegal values and hence even after
adding an enum, it is being reported as illegal in my case. However getting
that to work is another story.

Please confirm my understanding of your patches and since these patches have
not made their way to the upstream kernel, will have to use them myself
directly. By the way, I'm using 2.6.32.10 (you know..the long-term kernel)
and I couldn't find any of your changes in them but then again I couldn't
find it in the latest 3.12 version either.




--
View this message in context: http://linuxppc.10917.n7.nabble.com/BookE-branch-taken-behavior-vis-a-vis-updating-the-NIP-register-tp77960p78036.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.