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社區分享所有這些內容。