3

使用 NDK r8c、Eclipse 4.2、Windows 7 64

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

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

有没有人分析过 gdb 以查看问题所在？如果是这样，有什么建议吗？

4

1 回答 1

3

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

我想不出静态库会减慢速度的任何原因，但我必须承认我没有考虑过它们。您是否有特定的理由相信这一点，或者这只是为了说明您的调试需求的规模和范围而发表的评论？

我们已经开始研究步进问题，但还没有任何东西可以分享。基本上，瓶颈是 ADB（尤其是在 Windows 上）。此外，在单步执行时，GDB 和 gdbserver 之间有很多闲聊，尤其是当您使用带有本地窗口、注册窗口、表达式窗口、堆栈窗口等的 IDE 时.，每一步都更新。这是很多可能会针对 IDE 用例进行优化的喋喋不休。

我们正在考虑的一些用于加速步进的修复将是特定于 IDE 的：

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

  • 实现 GDB 和 gdbserver 之间的“超级数据包”通信... 封装特定于 IDE 的通信的数据包，以最大限度地减少 GDB 和 gdbserver 之间的干扰。

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

于 2013-01-14T21:40:15.000 回答