pegasus,

Were you able to achieve the intended behavior with any of the suggested RFC
patch?

Thanks!


pegasus wrote

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

quoted

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).  

*

quoted

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

quoted

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.)  

*

quoted

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.

*

quoted

/

quoted

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.

/

quoted

 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-tp77960p83658.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.