C 如何在ARM上使用kgdb？？

Im使用

ARMv7

作为目标机器。我已经为target编译了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

在此之后，默认情况下会进行一些命令通信

q支持的

从主机发送到目标。但目标不支持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文件。这是一个汇编文件，仅此而已。这个平台有几个用汇编语言编写的源文件

这是正常的，因为一些指令，特别是引导序列和其他“低级”功能是在汇编程序中编写的，因为这更容易

正如注释中已经写的那样，gdb需要源代码在调试时浏览它们。在调试部分中，包含调试符号，并在使用

-g

运行gcc时生成，其中“仅”引用源文件、行和列等。有关使用gcc调试符号的更多信息和更多链接，请参阅

---

kgdb正在寻找

head.S

，这是一个很好的迹象，表明你在做正确的事情。如果您有可用的源代码（可以很简单地解开正确版本的tarball），只需在这个源代码树中运行kgdb，或者使用

-d

参数添加源代码搜索路径，当然是在您的开发机器上

最终，主机到目标的通信仅建立了线路延迟BCO。开发机器中的内核源代码和超时问题之间没有关系

对于某些命令（如

qOffset

和

qSupported

）的超时问题，可通过使用GtkTerm而不是minicom作为串行端口通信工具来解决。 不同之处在于GtkTerm中的“线路延迟”选项。因此，当配置为~250时，此后不会出现超时消息。只需建立连接并在默认断点处等待。如果有人知道如何在minicom中设置这个

“线路延迟”

，对大家都会更有帮助

当然，我们需要执行

list

命令的源代码。但是如果没有这些源代码，我们也可以进行调试，即

si，bt

可以在

vmlinux

和

system.map

的帮助下执行

---

注意：：不需要设置调试远程1。这提供了主机到命令通信的详细显示。有关更详细的视图，

设置调试序列1

我不确定，但是你有在“主机”上编译的内核用于调试吗您没有将代码移动到其他任何地方？这就是它无法找到源代码的原因。

kgdb

是否要求源代码可用？也许有一个命令行选项告诉

kgdb

不要查找代码。在kgdb常见问题解答中：“gdb需要参考源代码文件和vmlinux或模块对象文件。由于gdb在开发机器上运行，这些文件必须存在于开发机器上。”不幸的是，您需要源代码。最小的Buildroot QEMU设置也会带来麻烦：