C#でも最後の砦はアセンブリコード

今VS2013ですが、昔からデバッガでは、アセンブリコードでもデバッグ出来ました。

「もちろん、C#でも!!」

「.pdb入手してMyCode以外もデバッグ出来るようにしたら、ランタイムやOSSのライブラリもデバッグ出来ますよ」

「まあ、普通にC#でデバッグしても良いんですが・・・」

(2016/02/09追記)

NuGet Package開発者の皆さん！！.pdb配布お願いします。

シンボル用Package作らなくてもpackage/files/file/@srcで追加できますよ！！

C#オンリーだと記憶にないかもしれませんが、アンマネージデバッグも有効にしていると、シンボルが見つからない時に、呪文のようなコード出て慌てた経験はありませんか?

それがアセンブリコードです。

「ILじゃないですよ」

少し似てますが・・・

「アンマネージC++ではおなじみです」

「C++のコードからアセンブリコードや16進数のマシンコードもファイルに出力できますし」

/FA、/Fa (リスティングファイル)

C#でアセンブリコードでデバッグするのも簡単です。

ブレークさせる
Debugメニュー>Windows
DissemblyとRegistorsを選択

で表示&デバッグ出来ます。

「いつでもC#のソースとアセンブリコードでデバッグ出来るので、もしもの時に安心ですね」

ILを見ても良いですが、マシンレベルではアセンブラに変換されて実行されるので、何か腑に落ちないことがあるときは、頼りになります。

「アセンブラに展開した時の各処理命令のCPUサイクル数を足し算すれば、実装方法によってパフォーマンスが違う理由も納得がいく」

「メソッドコールはコストがかかるって言うけど、レジスタをスタックに退避してから、コードを実行して、終わったらスタックからレジスタを復元するので、アセンブラを見たらあたりまえ」

「でも、最適化でインライン展開してくれるときもある」

「デバッグ版とリリース版は別のプログラムだから・・・」

まあ、非同期とか、システムコールとか、I/Oが挟まったら、そんなに簡単な話じゃありませんが・・・