我们使用的是某个供应商的定制芯片。供应商还提供了一个自定义编译器和相关工具(基于GCC(，包括芯片的模拟器，该模拟器支持通过GDB使用eclipseCDT对模拟器进行符号调试。
GDB调试基于修改后的GDB.exe与GDB服务器存根对话，两者都由供应商实现。eclipse CDT和修改后的gdb.exe之间的通信自然基于MI协议，修改后的gdb.exe和gdb服务器存根之间的通信基于RSP协议，这是可以预期的。
我们已经为这个定制芯片实现了一个模拟器，以避免在非硬件特定的调试中过度依赖模拟器。该模拟器使用与模拟器一起使用的编译器生成的相同ELF文件。为了简单起见，我们在模拟器中实现了GDB服务器存根，目的是它可以替代模拟器。
我们已经完成了基本工作，但在处理vCont命令时遇到了问题。由于我们不需要多线程支持，所以我们实际上不需要支持vCont命令。因此，为了响应QSupported命令，我使用vContSupported-标志进行响应。
然后，在从断点继续之后，当我得到vCont时查询，对此我用空响应(RSP数据包+$#00(进行回复，以指示(根据文档("；不支持"vCont"数据包&"；。
尽管如此，在下一个命令中，我仍然会收到一个vCont；s： 0；c： 0命令。我不知道如何处理这个命令？：
- 它是否表示"step"后面跟着"continue"(在默认线程上(？这与简单的"继续"有何不同，即为什么不只是vCont；c： 0
- 为什么尽管有否定的vContSupported标志和对vCont的空响应，我仍然得到一个vCont命令就在这个命令之前
注意，在eclipseCDT(具有"详细控制台模式"(中，控制台中有两个相同的警告：警告：无效的远程回复："；，响应2个vCont命令，但没有其他错误详细信息。因此，他们修改后的gdb.exe可能不喜欢空回复，因此继续输出vCont命令，而不是默认的单个"s"、"s"、"c"或"c"命令。
还要注意的是，我无法访问供应商修改后的gdb.exe或gdb服务器存根的来源——事实上，他们对任何关于gdb服务器stub如何处理这一问题的查询都完全没有反应。
是否有人在vCont命令中遇到过类似的情况？你应该如何处理？
根据Andrew的建议，从他上面的评论中设置debug remote 1，我至少弄清楚了警告适用于哪些响应。
经过更多的研究/谷歌搜索，这有助于发现vCont;s:0;c:0，即"步骤然后继续"行为是软件断点的典型行为：
- 在执行暂停(暂停或断点命中(时恢复原始内容
- 恢复(continue(时：
- 执行一步以超越当前断点，因为断点在执行断点的行/指令之前停止
- 执行后根据断点指令更改内存内容/寄存器等
- 然后继续执行
因此，您现在获得了一种复合vCont;s:0;c:0命令，其中包括要将其应用到的适用线程，而不是单个s命令和单个c命令来实现上述功能。需要注意的是，对vCont;s:0;c:0命令的回复就是对最终c:0子命令的回复——您可以接受s:0子命令的结果。
我仍然不知道为什么vCont?命令的空响应被忽略。我的目标中只有一个线程，在此之前，在对qC线程的响应中，用qC0进行响应，指示"0"；没有特定的线程"；。事实上，通过上面的调试设置，eclipseCDT跟踪显示：
Sending packet: $vCont?#49...Ack
Packet received: OK
Packet vCont (verbose-resume) is supported
由于某种原因，它忽略空应答(意味着"不支持'vCont'数据包"(，并返回到"vCont'"；(详细简历(是受支持的"；。
但好吧，既然我似乎必须支持vCont....命令，我就这么做吧。