Hello. I was reading the source code for the debug exception under powerpc. I saw that BookE processors stop before (actually) taking a branch. Hence in order to force it to take that branch and then stop, the source code for it had to be "hacked' to (temporarily) enable single step until the branch instruction has been taken, thereby mimicing the BookS behavior.
By doing this, I believe we would want the exception to be triggered after the branch has been successfully taken. Hence I put a printk to print the value of the instruction that actually caused the exception. I was assuming that initially a debug breakpoint would be hit on the branch instruction (assuming the branch is supposed to be taken). Now since at this point in time, the branch instruction has NOT finished, the kernel, after merely disabling the BT bit in DBCR0 and enabling IC bit in DBCR0, returns. At this point I was assuming we will see another exception at the very same instruction in userspace. However, when printing the NIP it becomes clear that when it gets to the debug exception handler after being (temporarily) set to single step, NIP points to the instruction after the branch instruction. To me, it appears that, after disabling BT (branch taken) debug event monitoring (and enabling single stepping), it does not catch an exception at that very same branch instruction, instead it catches an exception for the subsequent instruction. Sorry for the repetition but I wanted to clarify what I am seeing here. May be this IS the way it is supposed to behave (which means my thinking about it is flawed). I am a bit confused here. Please let me know more..Im keen to hear from you folks. -- View this message in context: http://linuxppc.10917.n7.nabble.com/BookE-branch-taken-behavior-vis-a-vis-updating-the-NIP-register-tp77960.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
