4
votes

I am debugging linux ubuntu kernel using kgdb / remote gdb. I have 2 computers - ubuntu target and windows host. Computers are connected using serial port and null-modem cable.

KGDB support is enabled in target ubuntu system, command options fro KGDB:

kgdbwait kgdboc=ttyS0,115200

On my Windows system i have MinGW gdb build (x86_64):

GNU gdb (GDB) 7.4 Copyright (C) 2012 Free Software Foundation, Inc. This GDB was configured as "x86_64-w64-mingw32".

I start my target system and it waits till remote debugger connection. I enter the following commands in GDB window:

(gdb) set remotebaud 115200                                                
(gdb) target remote COM4

My gdb is able to connect to target and prints the following:

Remote debugging using COM4
???() at kernel/debug/debug_core.c:1043 wmb(); /* Sync point after breakpoint */

I then enter command to set breakpoints to be able to return to gdb when OS is booted:

(gdb) b sys_sync

Breakpoint 1 at 0xffffffff8124a710

I also tried hardware-assisted breakpoints in another run of same setup:

(gdb) hbreak sys_sync

This breakpoint setup should lead to kernel beak back to debuger when i enter sync command from target ubuntu console.

After i hit continue in GDB, OS is booted OK, but i never able to bring control back to gdb. I tried setting breakpoints on sys_sync, i tried

echo g > /proc/sysrq-trigger

in all cases with no success.

Very interesting: if i dont initially set breakpoint in sys_sync, entering sync command later does nothing. If i set sys_sync breakpoint, entering sync command later do halt target computer completely - so i suppose breakpoint actually set in this case.

How to break into debugger? GDB becomes irresponsive to any CTrl-C commands, so no way to continue debuging after i initially hit continue.

May be architecture incompatibility (Windows gdb - Linux target) - but seems like breakpoints are really set.

Please help

2
same problem here...4pie0

2 Answers

0
votes

On your Test machine: login as a superuser.

sudo su

and after that generate a sysrq-trigger

echo g > /proc/sysrq-trigger

After this your target machine should freeze but the dev machine should break into target.

0
votes

Lower the baud rate on both ends. In my experience, while the 115200 baud rate is theoretically supported, it rarely works properly. I recommend dropping the baud rate down to 9600 (on both ends), and finding success. Once that is achieved, then you can step the speed back up one step at a time. I am rarely able to get the kgdb to work reliably beyond 34K baud, and often lower. And I have also made sure to use the proper RTS/CTS cross linked connectors, some store bought, and some hand-made. It never matters, I think the problem is some issue in kgdboc on the SUT side that does not really always work at full 115200 baud rate. Solution is just to lower the baud rate to 9600. The data is small, so the lower speed does not hurt anything, and having it work reliably is worth any speed penalty.