GDB-Server vCont 命令处理

Question

我们使用的是某个供应商的定制芯片。供应商还提供定制编译器和相关工具（基于 GCC），包括芯片仿真器，支持使用 eclipse CDT 通过 GDB 对仿真器进行符号调试。

GDB 调试基于修改后的 gdb.exe 与 GDB 服务器存根的通信，两者均由供应商实现。 eclipse CDT 和修改后的 gdb.exe 之间的通信自然是基于 MI 协议，而修改后的 gdb.exe 和 GDB-Server 存根之间的通信是基于 RSP 协议，这是可以预料的。

我们为此定制芯片实现了一个模拟器，以避免过度依赖模拟器进行非特定于硬件的调试。该模拟器使用与模拟器一起使用的编译器生成的相同 ELF 文件。为了简单起见，我们在模拟器中实现了 GDB-Server 存根，目的是它可以成为模拟器的替代品。

我们已经掌握了基础知识，但在处理 vCont 命令时遇到了问题。由于我们不需要多线程支持，因此我们实际上不需要支持 vCont 命令。因此，为了响应 QSupported 命令，我使用 vContSupported- 标志进行响应。

然后，从断点继续运行后，当我收到 vCont? 查询时，我会回复一个空响应（RSP 数据包 +$#00）以指示（根据 文档）“不支持“vCont”数据包。”。

尽管如此，我仍然在下一个命令中收到 vCont;s:0;c:0 命令。我不知道如何处理这个命令？:

• 它是否表示“步骤”后跟“继续”（在默认线程上）？这与简单的“继续”有什么不同，即为什么不只是 vCont;c:0 ？
• 为什么我仍然收到 vCont 命令，尽管有否定的 vContSupported 标志并且对 vCont 的响应为空？ 在此命令之前？

请注意，在 eclipse CDT（使用“详细控制台模式”）中，控制台中有 2 个相同的警告：“警告：无效的远程回复：”，响应 2 个 vCont 命令，但没有其他错误详细信息错误是什么。因此，他们修改后的 gdb.exe 可能不喜欢空回复，因此继续输出 vCont 命令，而不是默认的单个 's'、'S'、'c' 或 'C' 命令。

另请注意，我无权访问供应商修改后的 gdb.exe 或 GDB-Server 存根的源代码 - 事实上，他们完全没有响应任何有关其 GDB-Server 存根如何处理此问题的查询。

有人经历过与 vCont 命令类似的事情吗？你应该如何处理这个问题？

Answer 1

根据安德鲁的建议，从他上面的评论中设置

debug remote 1

，我至少设法弄清楚警告适用于哪些响应。

经过更多研究/谷歌搜索后，这有助于找出

vCont;s:0;c:0

，即“先执行然后继续”行为是软件断点的典型行为：

• 执行停止时（暂停或断点命中）恢复原始内容。
• 恢复（继续）时：
  • 执行一步以超越当前断点，因为断点在执行断点的行/指令之前停止。
  • 执行后根据断点指令更改内存内容/寄存器/等。
  • 然后继续执行。

因此，您现在获得的是一种复合

s

命令，其中还包括要应用该命令的适用线程，而不是使用单个

c

命令后跟单个

vCont;s:0;c:0

命令来实现上述目的。需要注意的是，对

vCont;s:0;c:0

命令的回复是对最终

c:0

子命令的回复 - 您吞下了

s:0

子命令的结果。

我仍然不知道为什么对

vCont?

命令的空响应被忽略。我的目标中只有一个线程，在此之前，在对

qC

线程的响应中，用

qC0

进行响应 - 表示“没有特定线程”。事实上，通过上述调试设置，Eclipse CDT 跟踪显示：

Sending packet: $vCont?#49...Ack
Packet received: OK
Packet vCont (verbose-resume) is supported

由于某种原因，它忽略空回复（意味着“不支持‘vCont’数据包。”），并恢复为“支持（verbose-resume）”。

但是好吧，因为看来我必须支持

vCont....

命令，所以我就这么做了。