14

我ARMv7用作目标机器。我已经2.6.34.13为目标编译了 Linux 源代码。

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

Target加载了新内核，并在命令提示符下启用了 KGDB。

$ echo ttyAMA0 > /sys/module/kgdboc/parameters/kgdboc 
$ echo g > /proc/sysrq-trigger

Entering KGDB... 显示消息并等待命令。

在主机端，

$arm-none-linux-gnueabi-gdb vmlinux

    gdb > set remotebaud 115200
    gdb > set debug remote 1
    gdb > target remote /dev/ttyS0

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

  1. qSupported从主机发送到目标。但目标不支持 qSupoted，因此返回 $#00。同样?，HC-1命令已发送但收到正确的响应。

  2. 但是qOffsets命令没有收到来自目标的任何响应。

我怀疑vmlinux。因为如果我提供listgdb，它不会显示 10 行代码，而是说

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

注意：：内核编译在服务器中完成。所以开发机器中没有可用的源。但 arm-gdb 似乎在寻找 head.S。

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

4

2 回答 2

1

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

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

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

kgdb 正在寻找的head.S是一个好兆头，表明您正在做正确的事情。如果你有可用的源（它可以像解压缩正确版本的压缩包一样简单）只需在这个源树中运行 kgdb 或使用-d参数来添加源搜索路径，当然是在你的开发机器上。

于 2013-01-12T07:54:49.897 回答
1

最后，主机到目标的通信只建立了线路延迟的 bcos。开发机器中的内核源与超时问题没有关系。

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

是的，当然，我们需要list执行命令的源代码。但也没有这些源，我们可以调试 iesi, bt可以在vmlinuxand的帮助下执行system.map。

注意：：设置调试远程 1 不是必需的。这给出了主机到命令通信的详细显示。如需更详细的视图，set debug serial 1.

于 2013-01-16T12:23:59.457 回答