In i386 whenever the breakpoint instruction is hit the ip is increased to the next instruction address. And then it is decremented since we want to restore and continue from the instruction in whose place breakpoint instruction was placed. And then processor resumes from this instruction address.
Whereas in arm the pc is never incremented to point to next instruction, it keeps pointing to breakpoint instruction. In case of compiled breakpoints the kgdb nor gdb doesn't know about this breakpoint and hence the pc has to be explicitly incremented (Thats what the patch does). Regards, Girish. On Fri, 2006-04-21 at 07:23 -0700, Tom Rini wrote: > On Fri, Apr 21, 2006 at 05:47:32PM +0530, Girish Shilamkar wrote: > > > If gdb is detached from the kernel on arm then it hangs. Though it can > > attach again and can continue. > > The problem occurred as in arm, pc is at same location where the > > breakpoint occurred. And this breakpoint happens to be compiled > > breakpoint (^C) one needs to increment the pc to next instruction. > > This patch does this in kgdb_arch_handle_exception. > > I don't see the problem. Isn't this the correct, defined behavior? We > don't have anything like this on other architectures. Or is it because > of the it's not a real breakpoint, it's a known/special bad instruction > games? I assume that's why ARM is special here, just want to confirm. > Thanks! > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
