Santosh Shukla wrote: > Hi All, > > Kernel Version : 2.6.30 > Arch : x86 > > I have tried KGDBOE (kgdb over Ethernet) on v2.6.30 from linux-2.6-kgdb.git > jwessel tree. I found that, After hitting the breakpoint, and then saying > continue, console throws the message like " Cannot remove breakpoints because > program is no longer writable. " After that, I have to exit from current gdb > session to new gdb session so as to "delete" all the previous breakpoint and > get the console login prompt. > > Following is the test log: > > Host Side: > ======================================================================================== > [r...@localhost linux-2.6-kgdb]# gdb vmlinux > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-linux-gnu". > For bug reporting instructions, please see: > (gdb) target remote udp:10.161.3.199:6443 > warning: The remote protocol may be unreliable over UDP. > Some events may be lost, rendering further debugging impossible. > Remote debugging using udp:10.161.3.199:6443 > kgdb_breakpoint () at kernel/kgdb.c:1807 > 1807 wmb(); /* Sync point after breakpoint */ > (gdb) b sys_sync > Breakpoint 1 at 0xc10a7dcd: file fs/sync.c, line 41. > (gdb) c > Continuing. > [New Thread 1415] > [Switching to Thread 1415] > Cannot remove breakpoints because program is no longer writable. > It might be running in another process. > Further execution is probably impossible. > > Breakpoint 1, sys_sync () at fs/sync.c:41 > 41 do_sync(1); > (gdb) c > Continuing. > Cannot remove breakpoints because program is no longer writable. > It might be running in another process. > Further execution is probably impossible. > >
You could have stopped here in your series of commands. At this point gdb is not likely restoring the IP register correctly and as a result the kernel is going to crash because it is executing instructions out of order or in some cases, skipping an instruction. Looks to me like it is gdb or gdb configuration problem. But there is no way to know for certain without looking at what it was trying to do when talking to kgdb. You probably want to take a look at what gdb is transmitting to and from the kernel. Before you connect to the target system you execute: set debug remote 1 That will print out all the information going between gdb and kgdb. Jason. ------------------------------------------------------------------------------ _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
