Question

我使用ARMv7作为目标计算机。我已经为目标编译了Linux源2.6.34.13。

目标通过串口使用minicom与主机（Linux开发机器）连接。

目标加载了新内核，并在命令提示符下启用了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从主机发送到目标。但目标不支持qSuppoted，因此返回$＃00。类似?，HC-1命令已发送但收到正确答复。
但是qOffsets命令没有收到目标的任何响应。

我怀疑是vmlinux。因为如果我在gdb中给出list，它就不会显示10行代码，而是显示

arch/arm/kernel/head.S : No such file or directory.

注意::在服务器中完成内核编译。因此在开发机器中没有可用的源。但看起来，arm-gdb正在寻找头部。

我不确定我在做什么错误。我需要为整个内核加载符号。在这方面指导我。

Answer 1

kgdb正在寻找head.S不是错误。如果你看here，你会看到源树中有一个head.S文件。这是一个汇编程序文件。这个平台有几个用汇编程序编写的源文件。

这是正常的，因为一些指令特别是启动序列和其他“低级”功能是用汇编语言编写的，因为它更容易。

正如已经在评论中写的那样，gdb需要在调试时浏览它们。在包含调试符号的调试部分中，当使用-g运行gcc时生成调试部分，其中包含对源文件，行和列的“仅”引用。有关更多信息，请参阅here以及有关使用gcc调试符号的更多链接。

kgdb正在寻找head.S，这是一个好的迹象，表明你做得对。如果您有可用的源（并且它可以像解开正确版本的tarball一样简单），只需在此源代码树中运行kgdb，或使用-d参数添加source-search-path，在您的当然是开发机器。

Answer 2

最后Host to Target通信建立了线路延迟的bcos。开发机器中的内核源与超时问题之间没有关系。

对于某些命令的超时问题，使用GtkTerm而不是minicom作为串口通信工具来解决qOffset和qSupported。差异是GtkTerm中的“线路延迟”选项。因此，当配置为~250时，此后没有超时消息。只需建立连接并在默认断点处等待。如果有人知道如何在minicom中提供这个"line delay"对每个人都会更有帮助。

是的，我们需要list命令的源代码才能执行。但是，如果没有这些来源，我们可以进行调试，si, bt可以在vmlinux和system.map的帮助下执行。

注意::设置调试远程1不是必需的。这样可以详细显示主机到命令的通信。有关详细信息，请set debug serial 1。

如何在ARM上使用kgdb？

2 个答案: