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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
