NDK r8c、Eclipse 4.2、Windows 7 の使用 64
私は以前、(他のプラットフォームでは、ギガビット イーサネット経由で) リモート デバッガーを使用して、ローカル デバッグと変わらないと感じた大規模な C++ コードベースを使用しました。SDK に付属の Java デバッガーも高速に動作します。したがって、なぜ gdb の接続とコード行のステップ オーバーが非常に遅いのか、私は非常に困惑しています。
約 20 の静的ライブラリと 1500 のソース ファイルで構成される現在のアプリケーションでは、接続に約 15 秒、ステップ実行に約 2 秒かかります。足踏みの方が気になります。
問題が何であるかを確認するために gdb のプロファイルを作成したことのある人はいますか? もしそうなら、何か提案はありますか？
私は持っている。私のコホートと NVIDIA の私は、この問題に対処するために AOSP にいくつかのコミットを行ってきましたが、私たちの焦点は共有ライブラリ (シンボルの読み込みパフォーマンスと保留中のシンボルの解決) にありました。solib 読み込み処理を 6 倍高速化しました。(ただし、独自の作業を行った後、その 6x のうち 3x が 7.5 で GNU によって上流で既に解決されていることを発見しました... そのため、再発明を放棄し、関連する 7.5 パッチを Google の NDK リポジトリに提出しました。古い 7.3 GDB です。) 私たちのスピードアップはすべて r8d にあると思いますが、確認していません。
静的ライブラリが速度を低下させる理由は思い浮かびませんが、それらについては何も考えていないことを認めなければなりません。そう信じる具体的な理由はありますか?それとも、デバッグのニーズの規模と範囲についての見通しを示すためのコメントでしたか?
足踏み問題への取り組みを開始しましたが、まだ共有できるものはありません。基本的に、ボトルネックは ADB (特に Windows の場合) です。さらに、ステッピング時に、特にローカル ウィンドウ、登録ウィンドウ、式ウィンドウ、スタック ウィンドウなどで IDE を使用している場合、GDB と gdbserver の間で多くのチャット通信があります。 .、各ステップですべて更新します。これは、IDE のユースケースに合わせて最適化できる可能性のある多くのおしゃべりです。
ステップアップを高速化するために検討している修正の一部は、IDE 固有のものです。
Python スクリプトを使用して、IDE ではなく GDB でウォッチ式を前処理します。
GDB と gdbserver の間で通信する「スーパーパケット」を実装しています... GDB と gdbserver の間のおしゃべりを最小限に抑える方法で IDE 固有の通信をカプセル化するパケット。
これらすべてを Android コミュニティと共有する予定です。