Nsight Tegraがあまりに強力だったので、逆に標準のndk-gdbではどこまで出来るのだろうとテストしてみることにしました。
以前にLinux(Ubuntsu)環境でAndroid開発用の環境を作った記事(ここ)がありました。この環境を使ってテストしてみます。
当時はNDK r8bを使用していましたが、あれから結構時間も経ったので進化している部分もあると思い、現在の最新 NDK r8e を用いてみることにしました。
以前でもブレークポイントはひとまず張れること、変数がみれることは確認していました。
そこで Nsightで出来たことが ndk-gdb では出来るかという点で見てみたいと思います。
Jni Proxyタイプのアプリケーションで、ネイティブアプリ側にブレークポイントを指定できるか？
いきなり一番難しいケースにトライしてみます。これが出来ればかなり優秀かと。
以前はコツがあったのですが、今回はそれ無しでいきなりブレークポイント指定してみます。
ソースコードは先日のものを使用し、ネイティブアプリ側のapp_init関数にブレークポイントを指定してみます。
Java側でjniInitを呼ぶ直前でブレークポイントを設定してデバッグ実行し、停止した後で ndk-gdb を起動してみます。
このあたりはいつもの手順となっています。
ndk-gdbを起動した後で、ブレークポイントを指定しますが、このときネイティブアプリ側のsoがまだロードされていません。そのためロードされたときにブレークポイントが指定されるよう、pendingの問い合わせについては “y” を答えてあります。
この後、”c” で実行を継続し、Java側でも実行継続させて、ブレークポイントで停止するかどうかを見てみたいと思います。
・・・
無事に停止しました！！！以前はそれなりに大変だったのになかなかやるじゃないか ndk-gdb
メモリの表示と変数の表示について
JniProxyタイプのデバッグがNsight Tegraで出来たことで最強と思っていたので、ndk-gdbが出来るとは思っていませんでした。
なかなかやりおるのでコード追加して、前回NVIDIA Nsight Tegraで確認したメモリ表示や変数の表示についてチェックしてみたいと思います。
void testFunc() {
int* v = (int*) malloc( sizeof(int) * 10 );
for( int i = 0; i < 10; ++i ) {
v[i] = i ;
}
for( int i = 0; i < 10; ++i ) {
v[i] = i * 255;
}
free( v );
}
１つめのforが終わったところで v の中身やメモリ番地の中身を覗いて見た図。無事に変数やその確保したメモリの周辺状況を見ることが出来ています。
続いて、Nsight Tegraで出来なかった動的確保配列の中身表示と条件付きブレークポイント。
以下のように、うまく動作していることがわかります。
(条件付きで止まったことを確認するため、i の値を最後に確認してます)
逆アセンブルも出してみる。
gdbなのでコマンドを叩く手間はありますが、うまく動いているようです。
ここまで動いていたので、いざeclipseでソースコード見ながらステップ実行、としてみました。
ただ若干不安定で関数のステップインの挙動が怪しい状態でした。ndk-gdb直接触っていたらうまく動くのに。
機能的にはgdbが備えていてもそれをユーザーフレンドリーに操作する部分はまだまだのようです。
そういえば、ADTの新しい物は NDKのデバッグもサポートしたとか話があったので、最新状態で環境構築して再度トライしたらこの問題解決していたりしないかな～とおもっている次第です。
コメント