当 ddd “等待它准备就绪”时,gdb/dbx 在做什么?
我使用 ddd 作为 C++ 程序的 gdb 和 dbx 的前端。
很多时候,在没有任何明显原因的情况下,我会尝试下一步
,但它会挂起,并显示消息“等待 gdb 准备好”或“等待 dbx 准备好”。
有人知道他们正在做的事情需要很长时间并且没有产生明显的结果吗? 我可以阻止它发生吗?
请记住,已经加载了足够的内容,我很高兴在同一进程(并且在同一函数中)提前一分钟步进/下一分钟,因此无论他们正在做什么似乎都没有必要。此外,ddd 和 dbx 具有相同的行为模式(在许多不同的可执行文件和不同平台上)这一事实使我认为这是数据中的某些内容,而不是任一调试器中的错误。
I use ddd as a front-end for both gdb and dbx for C++ programs.
Quite often, without any apparent cause, I will try to next
and it will hang with the message "Waiting for gdb to get ready" or "Waiting for dbx to get ready".
Does anybody know what it is that they're doing that takes forever and produces no apparent results? And can I stop it from happening?
Bear in mind that enough stuff has already been loaded that I have quite happily been stepping/nexting a minute earlier in the same process (and in the same function), so whatever they're doing doesn't seem to have been necessary for that. Also the fact that both ddd and dbx have the same pattern of behaviour (in many different executables and on different platforms) makes me think it's something in the data rather than a bug in either debugger.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
GDB(这同样适用于 DBX)通过 MI 协议与 DDD 进行通信,MI 协议是命令行界面的标准化且明确的等效项。
备注:我的系统(Fedora 15)中的默认设置似乎是直接使用 CLI 进行通信,但我只注意到您用
--interpret=mi
描述的问题。例如,以下是获取线程列表的相应输出:
因此,您在 DDD 中看到的内容将与 CLI 中提供的内容非常相似,只有“表示层”不同。
根据我的经验,大多数 GDB 命令都非常快,至少当它们不依赖于调试对象执行时(例如
next
超过sleep(5)
)。所以你的问题有两种可能:^done
标签或 GDB 忘记了,因此 DDD 徒劳地等待其请求的终止在 DDD 的底部有
GDB 控制台
。尝试在其中输入一些 GDB 命令。如果 GDB 响应正确(我的情况),则意味着 DDD 不再与 GDB 同步。 (DDD 已经过时了,2009/02/11,而 MI 被 Eclise 广泛使用,所以我想我们知道该怪谁了……!)GDB (and the same applies for DBX) communicate with DDD with the MI protocol, which is a standardize and unambiguous equivalent of the command-line interface.
Remark: the default in my system (Fedora 15) seems to be that they communicate directly using the CLI, but I only noticed the problem you describe with
--interpret=mi
.For instance, here are the respective output to get the thread list:
So what you will see in DDD will be quite similar to what is available in the CLI, only the 'presentation layer' is different.
From my experience, most of GDB commands are very fast, at least when they don't depend on the debuggee execution (like a
next
over asleep(5)
). So there are two possibilities for your problem:^done
tag is missed by DDD or forgotten by GDB, so DDD waits in vain for the termination of its requestAt the bottom of DDD you have the
GDB console
. Try typing some GDB commands in there. If GDB responds correctly (my case) it means that DDD is not synchronized with GDB anymore. (DDD is getting old, 2009/02/11, and MI is extensively used by Eclise, so I think we know who has to be blamed...!)