Android NDK远程调试：gdb为什么这么慢？

Question

使用NDK r8c，Eclipse 4.2，Windows 7 64

我以前使用过远程调试器（在其他平台上，通过千兆以太网），对于大型C++代码库来说，它们与本地调试没有区别。 SDK附带的Java调试器运行速度也很快。因此，我很困惑为什么gdb连接和跨越代码行很慢。

在我目前的应用程序中，大约有20个静态库和1500个源文件，连接需要大约15秒，步骤需要大约2秒。我更关心步进。

有没有人曾对gdb进行过简要分析，看看问题是什么？如果是这样，有什么建议？

Answer 1

我有。尽管我们的重点是共享库（符号加载性能和待解决的符号分辨率问题），但我和NVIDIA的同事们为AOSP贡献了一些提交，以解决这个问题。我们已经将solib加载处理速度提高了6倍。 （尽管在完成我们自己的工作之后，我们发现6x中的3个已经在GNU上游解决了7.5，所以我们放弃了我们的改造，并将相关的7.5补丁提交给Google的NDK存储库，该存储库基于老版本的7.3 GDB）。我相信我们所有的加速都存在于r8d中......但我没有检查过。

我想不出为什么静态库会减慢速度，但我必须承认我没有给他们任何想法。您是否有相信的特定理由，或者仅仅是为了给出您对调试需求的大小和范围的看法而发表评论？

我们已经开始研究步进问题，但没有任何东西可以分享。基本上，瓶颈在于ADB（特别是在Windows上）。此外，在步进时，特别是在使用带有本地窗口，注册窗口，表达式窗口，堆栈窗口等的IDE时，GDB和gdbserver之间存在很多琐事通信。 。，每一步都更新。这是很多可能针对IDE用例优化的喋喋不休。

只是一些我们正在考虑为加快步将IDE特定的修复程序：

• 使用Python脚本来预处理GDB的监视表达式，而不是在IDE中。

• 实现在GDB和gdbserver之间进行通信的“超级数据包......”封装特定于IDE的通信的数据包，以最小化GDB和gdbserver之间的震荡。

我们打算与Android社区分享所有这些内容。