Santosh Shukla wrote: > I have done same test on ubuntu "gnu gdb 6.8-debian", and enabled "set debug > remote 1" option.. > > Observed that, After saying continue command, Looks like while switching to > new thread, gdb unable to remove the breakpoints from current thread. > > > Test log: > =================================================================================================== > r...@sri-desktop:/opt/GIT/KGDB-Git/linux-2.6-kgdb# gdb vmlinux >
A quick zoom in to the important parts. > (gdb) b load_module > > Breakpoint 1 at 0xc1046f58: file kernel/module.c, line 1915. > > (gdb) b sys_sync > > Breakpoint 2 at 0xc10aa2f1: file fs/sync.c, line 41. > > (gdb) c > > Continuing. > > Sending packet: $Z0,c1046f58,1#14...Ack > Packet received: OK > Here gdb asks kgdb to plant the "load_module" break point > > Sending packet: $Z0,c10aa2f1,1#62...Ack > > Packet received: OK Here is your breakpoint for sys_sync > > > Sending packet: $vCont?#49...Ack > > Packet received: > > Packet vCont (verbose-resume) is NOT supported > > Sending packet: $Hc0#db...Ack > > Packet received: OK > > Sending packet: $c#63...Ack > > Packet received: T05thread:0000000000000676; > Above was the internals of the continue the T05 means kgdb stopped in your user space thread. next gdb will look to see if stopped at a break point and rewind the IP register one byte if it did. > > [New Thread 1654] > > Sending packet: $g#67...Ack > > Packet received: > 18e0a60908e0a60963b2000018e0a609e4beabf69cbfabf6fcffffff63b20000596f04c19602000060000000680000007b008df67b00abf6ffff0000ffff0000 > Sending packet: $P8=586f04c1#c6...Ack > > Packet received: > > Packet P (set-register) is NOT supported > Sending packet: > $G18e0a60908e0a60963b2000018e0a609e4beabf69cbfabf6fcffffff63b20000586f04c19602000060000000680000007b008df67b00abf6ffff0000ffff0000#48...Ack > This is the is reverse the IP register by one byte. > Packet received: OK > Sending packet: $g#67...Ack > Packet received: > 18e0a60908e0a60963b2000018e0a609e4beabf69cbfabf6fcffffff63b20000586f04c19602000060000000680000007b008df67b00abf6ffff0000ffff0000 > [Switching to Thread 1654] > Sending packet: $z0,c1046f58,1#34...Ack > Packet received: E02 > To me it looks like like you used kgdbwait and set the breakpoints prior to the elf pages getting marked as read only, which is about the only way you can end up with this kind of failure unless there is a defect in the architecture specific support for reading/writing memory via probe_kernel... routines. The kernel option CONFIG_DEBUG_RODATA should not be set in your .config, if it is, you would need to use hw break points, use "help hbreak" in gdb to learn more about hw break points. One the x86 arch you are limitted to 4 hw break points. BTW the CONFIG_DEBUG_RODATA is documented in the kgdb documentation, perhaps there needs to be an FAQ about why it is not working, assuming this is the root of your problem. :-) Jason. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
