如何在ARM上使用kgdb？
我使用ARMv7作为目标机器。 我已经为目标编译了Linux源2.6.34.13 。
Target使用minicom通过串口连接Host（Linux Development machine）。
Target加载了新内核，并在命令提示符下启用了KGDB。
$ echo ttyAMA0 > /sys/module/kgdboc/parameters/kgdboc $ echo g > /proc/sysrq-trigger
显示输入KGDB …消息并等待命令。
在主机方面 ，
$arm-none-linux-gnueabi-gdb vmlinux gdb > set remotebaud 115200 gdb > set debug remote 1 gdb > target remote /dev/ttyS0
在此之后，默认情况下会发生一些命令通信。
-
qSupported从Host发送到Target。 但目标不支持qSuppoted，因此返回$＃00。 同样的?，HC-1命令已发送但收到适当的响应。 -
但
qOffsets命令没有收到目标的任何响应。
我怀疑是vmlinux。 因为如果我在gdb中给出list ，它就不会显示10行代码
arch/arm/kernel/head.S : No such file or directory.
注意::在服务器中完成内核编译。 所以在开发机器中没有可用的源。 但看起来，arm-gdb正在寻找头部。
我不确定我在做什么错。 我需要为整个内核加载符号。 在这方面指导我。
那个kgdb正在寻找head.S并不是一个错误。 如果你看这里你会看到源树中有一个head.S文件。 这是一个汇编程序文件。 这个平台有几个用汇编程序编写的源文件。
这是正常的，因为一些指令特别是启动序列和其他“低级”function是用汇编语言编写的，因为它更容易。
正如已经在评论中写的那样，gdb需要在调试时浏览它们。 在包含调试符号的调试部分中，当使用-g运行gcc时生成调试部分，除了其他部分之外，还有对源文件，行和列的“仅”引用。 有关调试符号与gcc的更多信息和更多链接，请参见此处 。
kgdb正在寻找head.S是一个好的迹象，表明你做得对。 如果你有可用的源代码（并且它可以像解开正确版本的tarball一样简单）只需在这个源代码树中运行kgdb，或者使用-d参数添加source-search-path，在你的开发机器上课程。
最后，Host to Target通信建立了线路延迟的bcos。 开发机器中的内核源与超时问题之间没有关系。
对于某些命令的qOffset问题，可以使用GtkTerm而不是minicom作为串口通信工具来解决qOffset和qSupported 。 差异是GtkTerm中的“线路延迟”选项。 因此，当配置为~250时，此后没有超时消息。 只需建立连接并在默认断点处等待。 如果有人知道如何在minicom中提供这种"line delay"对每个人都会更有帮助。
是的，我们需要执行list命令的源代码。 但是如果没有那些源代码，我们可以调试即si, bt可以在vmlinux和system.map的帮助下执行。
注意:: set debug remote 1不是必需的。 这样可以详细显示主机到命令的通信。 有关更详细的视图，请set debug serial 1 。