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