problems to connect GDB over an serial port to an KGDB build Kernel
i want to debug an MIPS linux driver from my 64bit suse machine over serial ttyS0. The used gdb works greate over LAN with the debugging of applications but not with kgdb over serial. I used this page and a few more to start the debugging but without final results.
My kernel is compiled with the following setting:
CONFIG_MAGIC_SYSRQ=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
CONFIG_CMDLINE="kgdboc=ttyS0,115200"
if i run the gdb:
gdb vmlinux
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) target remote /dev/ttyS0
i can observe the following output:
OUTPUT (GDB_TERMINAL):
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Sending packet: $qSupported:qRelocInsn+#9a...Ack
Timeout in mid-packet, retrying
Timed out.
Timed out.
Ignoring packet error, continuing...
Packet qSupported (supported-packets) is supported
warning: unrecognized item "qSupported:qRelocIns" in "qSupported" response
Sending packet: $Hg0#df...Nak
Sending packet: $Hg0#df...Ack
Packet received: Hg0
Sending packet: $?#3f...Packet instead of Ack, ignoring it
Ack
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Sending packet: $Hc-1#09...Nak
Sending packet: $Hc-1#09...Ack
Reply contains invalid hex digit 36
OUTPUT (REMOTE_TARGET):
+$?#3f09n+#9a$Hg0#df+09
Nothing more happens!!!
I also test the sysrq but the mentioned sysrq-option 'g' seems to do not to fit!
echo b > /proc/sysrq-trigger
#successfully reboot
echo g > /proc/sysrq-trigger
#prints only the help message (SysRq : HELP : loglevel(0-9) reBoot Crash termin .....)
Is the sysrq running correctly?
Is there somethin that i have missed?
Exists there a way to test the running kgdb on my remote device?
Answer
I had many issues to run gdb with kgdb over serial link. My host is an Intel x86 Linux machine and the target is ARM 32-bit Raspberry Pi 2. The target is connected with a USB to TTL Serial Cable. Here are the key problems and their solutions.
1) Do not use gdb concurrently with screen or minicom.
With minicom connected on the tty, GDB hangs and then crashes:
(gdb) target remote /dev/ttyUSB0
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
/build/gdb-cXfXJ3/gdb-7.11.1/gdb/thread.c:89: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected, further debugging may prove unreliable.```
And when screen connected, GDB fails to connect:
(gdb) tar rem /dev/ttyUSB0
/dev/ttyUSB0: Device or resource busy.
2) Corrupted packets and timeouts
Invalid packet, Bad checksum, Saw new packet start in middle of old one, Timed out
Use GDB supporting the target architecture. The default GDB on x86 (at least on Ubuntu) does not support an arm target. Use instead gdb-multiarch or the GDB corresponding to the cross-compiling toolset i.e. arm-linux-gnueabihf-gdb. List available architecutres with (gdb) set architecture command. The auto architecture was detecting the arm target correctly in my case.
3) KGDB must be triggered on the target prior to connect
Remote replied unexpectedly to 'vMustReplyEmpty': vMustReplyEmpty
Malformed response to offset query, qOffsets
GDB tries to connect, but the target is not in debug mode. The debug sysrq must be triggered before connecting with GDB. The keyboard shortcut was not working for me. Running the command echo g > /proc/sysrq-trigger through SSH as root works.
4) Configure the baudrate
warning: Invalid baud rate 115200. Maximum value is 38400. /dev/ttyUSB0: Invalid argument.
The baudrate configured must match between the kgdboc kernel parameter and GDB. In my case, the baudrate 115200 was not supported. Setting the baudrate to 38400 as suggested was necessary. Reboot the target with kernel cmdline: kgdboc=ttyAMA0,38400 and then:
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
0x800b4730 in kgdb_breakpoint ()
Once these issues were solved, kernel debugging worked as expected.