「 VisualStudio 」一覧

CRT非依存の続き


前回結構かいたつもりですが、それの補足や追加調査でわかったことを書いておきます。

C++は本当につかえない?

できることならC++のクラスとか使って開発したいですが、new/delete 使えなかった記憶があったので調べてみました。
 結果、通常のnew, delete を使用した際にはCRT依存が発生してしまいます。しかし!グローバルのnewをオーバーロードする方式で new/delete の処理を横取りすれば、この依存が発生しないことがわかりました。個人的にはすばらしい発見でした。(そもそも例外は使わない前提。前回の記事でOFFに設定していますし)

エントリポイントの設定について

前回エントリポイントの設定をするように書きましたが、実は他の方法があるようです。
規定のライブラリ省略をするように設定すると下記の関数がエントリポイントとできるようです。

どのみち規定のライブラリ名の省略オプションは有効にしておいた方がいいみたいですし、こっちのほうがよいのかもしれません。


CRT (C Runtime) に非依存とするために・・・


VisualStudio (Visual C++) を使って開発をしている際にちょっと厄介になってくるのが、CRTの選択についてどれにするかを決める点です。これは実行体(アプリケーション)を作っているときにはまだ軽微な話なのですが、ライブラリを作る際にはとても大変な話になってます。

というのも、デバッグ/リリース、そして、CRTのDLLリンク/スタティックリンクの組み合わせ、最近だとそれに 32bit/64bit という組み合わせを考えなくてはなりません。つまり 2x2x2 の8種類存在することになります。ライブラリの提供者になる場合、特にそのライブラリをパッケージとして納品するなどする場合には、これらの組み合わせのライブラリを1セットとする必要があると思います。

しかし!そんな8種類も納品したくない&動作テストしたくもないのが本音です。
ただ利用者にとっては自分のアプリケーションで使うために、一致するライブラリを選択できているのが望ましいです。数が多いと選択に困るかもしれませんが、ライブラリのせいで構成を縛られてしまう、という点だけは避けたいところです。またオープンソース等であればプロジェクト設定を変更して、利用状況に応じてオプションを変えることで対処することも可能です。・・・でも個人的にはこれもやりたくはない作業だと感じています。

ライブラリの個数を減らすことを考えてみる

8種類もあるのが大変なので減らすことを考えてみます。どうしても減らせないのは 32bit/64bit のケースでしょう。そもそもABIが違うのでこれはどうしようもありません。
ランタイムDLLを要求するケースはclr使う際には必要です。つまりC++/CLIを使って C#から使うようなケースでは必須となります。楽にGUIを作れるのでこれは考慮しておく必要があります。ただCランタイムのDLLについて配布先でインストールが必要になります。おなじみの再頒布ランタイムってやつですね。
スタティックリンクを使用する場合、exe単体配布で動くようにできるというのが最大のメリットでしょう。

つまりDLL/スタティックリンクどちらもメリット・デメリットがあります。つまり捨てられない・・・。

これらのランタイムは何を示しているかを考えてみます。
そう、CRT なので、Cランタイムのタイプがどれであるか、を決めているわけです。ということは、Cランタイムを使わない、CRT非依存を実現できればこれらの問題から解放される、と予想できます。
つまり、CRT非依存を実現できれば DLL/スタティックリンク の組み合わせはどちらでもよい(=最終exeをつくるプロジェクトに任せられる)ということになります。

次に Debug/Release の違いも検討してみます。DLL版においては Debug,Release で別々のランタイムDLLに依存することがわかります(Dependency Walker とか使えば簡単です)。でもやっぱり CRTに関係する実装が Debug/Release と切り替わるだけなので、CRTに非依存が実現できればこのDebug/Releaseの差異も気にしなくてよくなりそうです。

ここまでの予想をまとめると、「CRTに非依存にできれば x86用ライブラリと x64用ライブラリの2つを提供するだけでよくなる!」 となります。非常に魅力的です。
・・・現実問題としてデバッグ用ビルドは用意して提供する気がしますが。組み合わせとして4つ程度で済むというのはとても助かることじゃないでしょうか。

具体的にどう開発をするのか

CRT非依存の開発をするにあたってどうすればいいのか、ホントに実現できるのかという点で自分が調べた範囲でのメモをここに残しておこうと思います。

そもそもCRT非依存にして開発できるのか?という問題ですが、結構手間がかかりますが実現不可能ではありません。このときに使ってよいのは Windows API のみとなります。Cの標準関数は使用不可です。当然ですね。標準関数に含まれる機能が欲しいときには、自作 or Windows API で代替を探す、という感じになります。

たとえば、ファイル操作では fopen, fread, fwrite は使えません。代わりに CreateFile, ReadFile, WriteFile を使用します。printf も使えないので、自力で WriteFile にてコンソール用出力先にデータを書き込む方法で対処とかになります。これは結構大変です・・・。

もうちょっと具体的な話

基本的に C言語の範疇でコードを記述します。
またVisualC++のコンパイラが色々とデバッグ時に役立つ機能を埋め込んでくれるのですが、これらについてオフにします。だいたい以下のような設定をプロジェクトに行います。

  • デバッグ情報: プログラムデータベース(/Zi)
  • SDLチェック: いいえ (/sdl-)
  • 最小リビルドを有効にする: いいえ(/Gm-)
  • C++の例外を有効にする: いいえ
  • 基本ランタイムチェック: 規定
  • セキュリティチェック: いいえ(/GS-)
  • ランタイム型情報を有効にする: いいえ(/GR-)
  • インクリメンタルリンクを有効にする: いいえ
  • エントリポイント: (自分の決めたエントリポイント関数)

また ZeroMemory マクロも実際のところはmemset に展開されるので使用禁止ですし、配列や構造体を={0}のように記述して初期化する際にも memset が使用されてしまうようなのでこれも禁止です。

このようにしてアプリケーションを作っていく際には、慣れないうちには特にですが、ビルドしてできたexeをDependencyWalker で調査しつつ作業を進めるのがよいかと思います。そうしないとどこでCRT依存を混入してしまったのか見つけるのが大変です。


C++で UTF-8文字リテラルを使いたい


VisualStudio 2010 環境限定ではあるけれど、ソースコードがBOM付UTF-8であれ、ShiftJISであれ、文字リテラルを UTF-8 で処理させて、実行体Exeの中に格納できる方法を発見しました。

このようなコードを作成してWindows日本語版の環境下でビルドした場合、その実行体の中に含まれる文字列は、Shift JIS (MS932) となってしまいます。 これはビルド設定の「文字セット」の設定とは無関係で、元のソースコードがどの文字エンコーディングを使っているかにも関係なく、ShiftJISとなってしまうようです。
この状態がちょっと都合が悪いことがあって、出来上がった実行体の中に UTF-8 で文字列で格納しておいてほしいというのが実現したいことです。

すなわち、上記の文字列 「あああ」をエディタで(ShiftJISやUTF-8など)で通常通りに入力し、それをUTF-8化したままで exe の中に格納しておく、ということがやりたいわけです。

続きを読む


VisualStudio 2013をインストールしてみた


MSDNのほうではVisualStudio 2013がRTMになってダウンロード可能となったのでインストールしてみました。
今回はその記録です。

まず素のWindows7にインストールしようとしたら、セットアップできませんでした。
InternetExplorer10 を要求するようです。
DirectX SDKを使って開発している場合にはこれが少々問題になって、IE10インストール後はPiX for Windowsが使用できなくなるようです(詳しくはこちら)。
IE10のインストール後は、VisualStudio2012の付属のツールを使って調査して下さい、ということのようです。
・・・でもこれだとDirectX9が非対応のようで残念なのですが。時代的にもうDirectX9は積極的なサポートのほうは終了という意思の表れのように感じます。

ランタイムで気になった物のバージョンを調べてみました。

  • .NET Framework 4.5.1
  • VCランタイム 12.00.21005.1
  • Windows Kitsフォルダ内には 8.0 と 8.1 の両方のファイルが存在
    • d3dcompilerもそれぞれにあった。d3dcompiler_46/47.dll, d3dcsx_46/47.dll となっていて、これらは再配布可能フォルダにあった。

Windows8 RTMでは .NET Framework 4.5 だったのでわずかに上がってます。Windows7 SP1のころでは、.NET Frameworkは 3.5.1だったので、4がスキップされてますね。

続きを読む


現在のWindowsサイドバイサイドについて-続き-


前回は、VCランタイムをスタティックリンクして生成させるという話で終了しましたが、今回はその続きに当たるダイナミックリンク版のVCランタイムを使用しつつ前回の条件を満たす、ということを考えてみたいと思います。

前回はこちらに。 現在のWindowsサイドバイサイドについて

ここでは2005,2008と2010,2012での谷間によって、大きく違います。
2010以降で生成されたアプリケーションでは、VCランタイムに関する埋め込みマニフェストがないため、そのまま必要なDLLをexeと同じ場所にコピーしておくことで対処できます。
一方で、2005,2008はカレントに決められた名前でフォルダを作成してその中にDLLを配置する手法をとります。
これはプライベートアセンブリというものに該当します。

図示するとこんな感じです

-- Application.exe
      + Microsoft.VC90.CRT
          + msvc***.dll
          + Microsoft.VC90.CRT.manifest

Microsoft.VC90.CRT というフォルダはVCインストールフォルダでredistというフォルダの中で見つけることが出来ます。

このように配置してアプリケーションを動かしたいということは、その環境ではランタイムが入っていないわけですので、
Application.exe が要求するバージョンの Microsoft.VC90.CRT を配置しなくてはなりません。
ここがくせ者でして、VisualStudio2005,2008にはそれぞれで違った挙動を示してくれます(涙

  • 2005の場合
    • ビルド環境の最新状態のVCランタイムバージョンにバインドされる
  • 2008の場合
    • ビルド環境の最新状態のVCランタイムバージョンではなく、2008RTM版のランタイムバージョンにバインドされる

つまり、2005のこの挙動であれば、ビルド環境のredistフォルダからコピーして配置で問題なく動くようになるわけです。
一方、2008のこの挙動ではビルド環境のVCインストールフォルダのredistも最新状態のランタイムに更新されているため、redistフォルダからのコピーではバージョン違いにより動作させることが出来ない状態となります。

これらの挙動を修正するのに、exeが要求するランタイムバージョンを変更するという方法が1つあげられます。それが外部マニフェストです。
exeと同じ場所に、exe名(拡張子含む).manifestというファイルを作成することで、処理されるマニフェストを上書きする形で制御できます。ここにredist内で見つかったバージョンを要求するように書き換えてしまえばうまく動くという考えです。

この方法はXPまでであれば考え通りに動きますが、2003以降マニフェストの処理優先順が変わりました。そのため現在主流となっているWindows7周辺のバージョンでは埋め込みマニフェストが優先されてしまうため、動かない状態となります。

この状態でとれる案として以下のものが考えられます。

  1. 2008の場合において、ビルド時に
    _BIND_TO_VCLIBS_CURRENT_VERSION=1 (プリプロセッサ定義で指定する)
  2. 生成されたexeの埋め込みマニフェストを編集する

(1)の場合、ビルド時のVCランタイムバージョンにバインドされるようになります。
依存するライブラリ全てにおいてこのプリプロセッサ定義を行いexeを生成できれば、ビルド環境のredistからランタイムをコピーだけで動くようになります。
(2)の場合、mt.exe というツールを用いて、manifest取り出し → 編集 → 再度埋め込み という手順を行います。

具体的には、下記のような感じになります。

取り出し
mt.exe -inputresource:Application.exe;#1 -out:result.manifest

取り出したマニフェストファイルを開き、要求しているバージョンを変更します。

埋め込み
mt.exe -manifest result.manifest -outputresource:Application.exe;#1

以上で、exe単体で動かす場合の話は終了です。
しかし、オープンソースのライブラリや自作の他ライブラリを用いており、それがDLL版だったりすると話はまだ続きます。
これについてはまた次回に。


WindowsとVisualStudioの動作環境


Windows8 と VisualStudio 2005 の組み合わせキーワードで当ページに来る人もそれなりにいて、
ちょっと気になったので調べてみました。

参考 http://www.microsoft.com/ja-jp/dev/support/tools.aspx

この情報をまとめると、

開発PCが Windows7 なら VisualStudio 2005から2012まで使えるけれど、
開発PCが Windows8 なら VisualStudio 2010以降でなければならない。

ということでしょう。長らくVisualStudio 2008を使っていましたが、そろそろ 2012 に切り替えた方が良さそうに感じました。

VisualStudio 2012はWindows7以降だし、幅広くこれ1本と決めるなら 2010 を使えってことなのかもしれません。
しかし、2010以降は使用するツールチェインを切り替えられたはずなのですが、これを使って Windows8上でVS2008のツールチェインを使用するということもサポートされないのか?とちょっと疑問に思いました。


NVIDIA Nsight Tegra がすごい その4


前回、JniProxyタイプではうまくいかないです~の続きです。

動作させるためには、JavaJniAppのパッケージ(APK)に libNativeAppMain.so を含められればそれで完了です。
これをどうやって行うかですが、強引には以下の手順で実現することが可能です。

  • NativeAppMainをビルド。soファイルが出来る
  • JavaJniAppのビルド1。まず libJavaJniApp.soが作成される
  • JavaJniAppのビルド2。Java部分のコンパイルが実行される

上記のJavaJniAppのビルド1 or 2のタイミングで NativeAppMainの so ファイルを JavaJniApp/libs/armeabi-v7a の中にコピーしてあげればよいです。

成功すれば Apkファイルの中に libNativeAppMain.so が入っています。

一度実行してログを確認してみます。(起動後、戻るボタンでホームに戻るという操作を行っています)
うまく動いていればこのようにログが出ているはずです。

この時に、アプリケーション本体である nativeappmain.c の各関数にブレークポイントを仕掛けて、同じように実行してみます。
下記のスクリーンショットに示すように、ちゃんとブレークポイントが有効となって停止します!すばらしい。

タイミングコピーの自動化を狙う

先ほどの、手動でlibNativeAppMain.soを強引にタイミングを見計らってコピーするという方法はちょっと手間です。
タイミング失敗によるとまたビルドし直しになるし、ここは何とかして自動で解決するようにしたいです。

Nsight Tegra は、どうやら vs-android をも取り込んでいるようです。vs-androidではAntを使用していましたし、よくよく動作を見るとビルドのタスクをこなしているのはAntのようです。
ということは Ant の設定やスクリプトを変更すれば、この自動化も出来そうな気がします。

そこで build.xml の中身を覗いてみると、以下のようになっており、どうやらカスタマイズの余地がありそうです。

まずは JavaJniApp の build.xmlと同じ場所で custom_rules.xml を作成して、中身を以下のように設定します。

そうして、ビルドを実行してみると、以下のように上記の設定が実行されたことが確認できます。

JavaJniAppのsoが出来たタイミングが良さそうだろうと思うので、post-complie タイミングで実行されるように、下記の設定を custom_rules.xmlに記載します。

これで JavaJniApp をビルドして、既にできあがっている本体のsoをコピーすることが出来るようになります。

改善点は、上記の場合コピー元フォルダが Debug と決めうちしてあるため、構成に応じて変更できればさらに便利になりそうです。
改良した custom_rules.xml を下記に示します。これでビルド構成Debug/Releaseに対応できます。

まとめ

Eclipse+NDKでは苦しい JniProxy タイプのソースコードレベルのデバッグもNsight Tegraならば可能でした。
最近のWinGDB for Mobile Systems では試していないですが、このタイプのデバッグも出来るとなるとかなり便利です。
個人的には開発においては、Tegra(ICS以降)のAndroidを準備すると幸せになれると感じました。


NVIDIA Nsight Tegra がすごい その3


今回はNDKの開発で、割と使われるJNIProxyという手法で Nshight Tegra のデバッグブレーク機能は有効になるか?を確かめてみたいと思います。

このJniProxyという方法は、Android上ではアプリケーションの実行体イメージがメモリ上にまだ存在する場合、再利用してアプリケーションが動く、という挙動に対して解決する方法の1種です。
C/C++ネイティブ開発者の間では、.so 内のグローバル変数が初期化されずにアプリケーションが起動したように見えます。

詳しくはこちら(ホイール欲しい ハンドル欲しい: Android NDKの初期化とdllの分離)で説明されている内容です。

Java – JniProxy.so — Application.so というように、
JavaからはJniProxy.soを操作し、JniProxyが本当の意味のアプリであるApplication.soをロード・アンロードします。

Nsight Tegraを導入した Visual Studioでこのようなプロジェクトを作成するには、前回説明した複数のライブラリを用いて .so を作成するという方法に近い物があります。1点違う点があるのは、両者が so となっている点です。まずは、2つのプロジェクトを作成して、今回の概観を作ってみます。

  • NativeAppMain (ネイティブアプリケーションの本体)
  • JavaJniApp (JniProxy.soをもつJavaアプリケーション)

プロジェクトのタイプは、JavaJniApp は Android Application With Native Code で作成し、
NativeAppMainは Android Native Application で作成します。
これらをまとめるソリューションは testJniProxy として作成しました。

作成して、とりあえず必要なファイル名を変更したものが以下のようになります。

続いてプロジェクトの設定を変更します。
NativeAppMain は今回は .so 形式となるので Configuration Type を Dynamic Library(*.so)に変更します。
また JavaJniApp は NativeAppMain に依存するようにしておきます。
そして、JavaJniAppのプロジェクトの設定では、ライブラリ dl を使用するように変更しておきます( -l”dl” を追加のライブラリに入れる)

ここまで設定できたら、各ソースコードを編集します。
ほぼ上記で紹介したサイトのコードのままなのですが以下のようになります。
まずは動作確認の意味もかねて、onCreateでロードして、onPauseで終了が呼ばれるだけの単純なものにしてあります。

JniProxy.cpp

JavaAppMain.java

NativeAppMain.c

ここまででとりあえず必要な物はそろってはいるのですが、このまま実行するとNativeAppMainのロードが実は出来ません。
その理由は、NativeAppMain.so が JavaJniApp の apk の中に取り込まれないからです。
ちなみに libNativeAppMain.so は ソリューション以下の Android/Debug の中に存在はしているのですが、
今回のケースでは取り込まれないんですよね・・・。
VisualStudioのビルド前後のイベントを使用しても、取り込まれるようには設定できませんでした。

(解決策は次回へ続く。)


NVIDIA Nsight Tegra がすごい その2


NVIDIA Nsight Tegra 検証の第2弾です。
前回はほぼデフォルトで作成される状態のサンプルプログラムを実行させての動作確認だったので、今回はもう少し実際にあり得るケースで正常にデバッグが出来るのか、を試してみたいと思います。

今回のケース想定

 

2つのスタティックライブラリを使用して、.so を作成し、Javaから利用する。
要は libXXXX.a を複数リンクして、アプリケーション本体となる.soを作成、Javaはその呼出までの役割に過ぎない、というケースです。
ほぼ定番のケースだと思います。これで実用になるのか、試してみたいと思います。

こんなフォルダ構成で作成します。AppMainは Java+Native の「Android Application with Native code」タイプで作成します。

NVIDIA Nsightでスタティックライブラリ用プロジェクトはどう作成するか、ここが問題です。
現時点では、ウィザード等では設定できないようだったので、やや強引ですが既存のプロジェクトタイプで作成した後、設定を変更して対応することにします。

スタティックライブラリ用プロジェクトの作成方法

 

最初のプロジェクト作成で 「Android Native Application」を選択します。これはNativeActivity用の設定ですが、
ファイルの削除と設定変更だけで割と簡単にネイティブのスタティックライブラリ用に出来るので利用させて貰うことにします。

パッケージ名を聞かれますが、スタティックライブラリには不要なので適当に入力しておきます(例:org.aaa)。
プロジェクトが作成できたら、下記画面の通り、native_app_glue 関連のコードを削除し、デフォルトで作成される main.c の名前を変更しておきます。また、main.c の中身も全部削除して、動作検証用のコードにしておきます。
すでに既存のソースコードを持っているなら、main.cを削除して、それを登録しておくのでも問題ないでしょう。

そして、出力するタイプを “Make Application” から ”Static Libaray(.a)” に変更します。

ここまでの作業を同じように繰り返して、lib2を作成します。

lib1のソースコード内容例

lib2のソースコード内容例

続いて、「Android Application with Native Code」タイプで AppMain を作成します。
AppMain.java の onCreateメソッド内で、既に作成されている appmainNative() を呼び出すようにしておきます。
その後、AppMainのネイティブコード部分(AppMain.c)で、今用意したlib1,lib2の関数を呼出して、ブレークポイントがはれるかを確認してみます。
作成したら、AppMainのプロジェクトをスタートアッププロジェクトに指定しておきます。

AppMain.cのコード内容例

コードを作成したら、プロジェクトの設定を開いてで liblib1.a と liblib2.a をリンクするように修正します。
今回のフォルダ構成では、testTwoLibsフォルダ以下に Android/Debug というフォルダが作成され、この中に .a のファイルが出力されるようになっています。
“構成プロパティ” / Linker / Additional Library Directories の部分にこのフォルダを指定します。

そして、リンクするライブラリの指定は、“構成プロパティ” / Linker / Additional Dependencies の部分に指定します。
このときに、従来のVCではライブラリファイル名を設定していましたが、Nsight Tegraの場合では、-l”(ライブラリ名)” と指定するようです。(このやり方がわかる以前は、CommandLineで直接設定してました・・・)
うまくいかない場合には、CommandLineで直接指定するなどで対処できそうです。
gcc環境であることもポイントで、ライブラリファイル名が、libhoge.a の場合、上記のライブラリ名では hoge と指定する点に注意してください。

今回の例では、-l”lib1″ -l”lib2″を指定しておきます。

続いて、ブレークポイントを下記のように設定しておきます。今までの経験から Java – C の接続部である上記のコードにブレークポイントが張れて機能することはわかっているので、次の2点を確認したいと思います。

  • 外部ライブラリへのステップインは出来るか?
  • 直接外部ライブラリのブレークポイント設定は有効になるか?

ここで、外部ライブラリとは AppMain.so が利用している .a のファイルを指しています。

実行して、上記の1つめのブレークポイントで停止した後は、ステップインで lib1 のソースコード内へ突入できるかを確認してみます。

F5で実行して、mylib1Test関数にステップイン(F11)してみると、下記のように正常にステップインできました。

さらにこの後、F5で実行を継続させて様子を見ていると、下記のように正常に lib2 の関数内でブレーク発動できました。

まとめ

複数のスタティックライブラリを使って、soファイルを生成するタイプのアプリケーション開発では、今回試した内容からほぼストレス無く開発が出来るのでは無いかと思います。
また、記事で詳細に触れてはいないですが、lib1,lib2をソリューションから除外して、AppMainだけをリビルドして同様のことを試してみたところ、こちらも正常に関数内へステップインできました。
Nsight Tegraの出来の良さに感激です。

気になった点とか躓いた点とか

上記のテストで、アプリケーションが起動できない、妙な動きをするような場合は以下の点を確認してみてください。
自分でも陥ったポイントです。他にも発見&解決できた人は是非コメントくださいませ。

アプリケーションが起動できない(onCreate以降すすまないっぽい)
純粋にApplication with Native Code のプロジェクトを作成して、それが起動できるかどうかを確認。うまくいけばそれ以降の部分で問題があることになります。この後確認するのは lib1, lib2 が 正しく .a を出力する設定になっているかどうか、です。
自分の場合には、変更することを忘れて、ここを .so のままにしていたことがありました。このとき問題発生でアプリケーション終了という流れで、すごく悩みました。

他には、スタートアッププロジェクトをlib1やlib2のままになっていないかを確認。元々がNativeActivity用のプロジェクトを流用しているので、実は実行させようとすればできちゃうようで・・・。


NVIDIA Nsight Tegra がすごい


NVIDIA Nsight Tegra を導入してみました。これは Tegra Android Development Pack に含まれています。
これが結構便利で、Android のNDK開発では個人的には最有力候補になると思っています。
一昨年くらいの TADP は個人的にはマイナス評価で検証後見送ったのですが、今回は多少のデメリットがあってもこれを選択したい勢いです。

さて入手には登録を必要とするのですが、ちょっとややこしい感じだったので、まずはそれについて説明しておきます。
NVIDIAのDeveloper Programに登録し、ログインを行います。
そして、Tegra Registered Developer Program と Nsight Visual Studio Edition Registered Developer Program の2つを有効化します(ApprovedステータスになっていればOK)。
注意するのはさらに、有効化されたよメールが手元にくるまで、実際には有効化されていないということです。
このメールがくるまでしばらく待ちましょう。

Tegra Android Development Packは今現在 2.0 で、ダウンロードできた物は 2013-02-06 リリースのもののようです。
これをインストールすると Nsight Tegra もインストールされました。

Nsight Tegra は Visual Studio 2010 SP1 に統合され、対象とするAndroidのバージョンは 4.0以降に対応するようです。
先日のICONIA Tab A500 をICSアップデートの真の目的はこのためだったのです!

Nsight Tegra で出来ること

 

Visual Studio 2010 上で、JavaもC(ネイティブ)も同時に開発可能です。
そしてすごいのはビルドはもちろんのこと、待望のデバッグも可能となっています。今まではEclipseで何とかがんばっていたソースコードデバッグも、これだけで可能になります。Javaの部分ですらブレークポイントが設定できます。そしてデバッグ出力ウィンドウで、”Android Logcat”を選択すれば、ログの確認もVisual Studioで行えます。
ただ、Visual Studio だから仕方の無いことなのかもしれませんが、Javaに対するサポートは弱いようで、インテリセンスが効きませんでした。

インストールして試してみる

 

まずはプロジェクトを新規作成して出来るテンプレで設定および動作の確認をしてみます。
ここでは、Java+Nativeの構成をとれる Android Application with Native Code を選択します。プロジェクトの作成する場所は、スペースを含まないパスにする必要があるようなので、この点にだけ注意します。

続いて、パッケージ名を指定します。

logcatの出力をVisual Studioで確認出来るように有効化します。有効化した後は、出力ウィンドウで 「Android Logcat」 が選べるようになります。

最後に、プロジェクトの設定を開き、Javaもネイティブも両方ともデバッグブレークできるように設定を変更します。

これでひとまずの設定は完了です。

動作を確認するために、Java部分とC言語部分をちょっとコードを変更しておきます。
また、コードを編集した後には、ブレークポイントを仕掛けておきます。

C言語部分

それぞれにブレークポイントを仕掛けて、いつも通り F5 を押してデバッグ実行させてみます。もちろん、対象となるデバイスをUSBで接続しておいてください。

実行開始状態の図。ちょっと時間がかかるようです。

そして、実行後ブレークポイントで停止している図。

まとめ

このNsight TegraはAndroid開発、特にネイティブに重点を置いて開発する場合には、現時点では最強を狙える拡張だと思います。もうしばらく試用&検証してみてどのくらいのポテンシャルを秘めているか、探ってみたいと思います。WinGDB for Mobile Systemsが Androidのネイティブ開発で最強と思っていたのですが、なかなか製品として出てこないですね。そんな中このNVIDIA Nsight Tegra の登場は非常にうれしい限りです。

情報元: https://developer.nvidia.com/nvidia-nsight-tegra