ILASM

Transcription

1 IL アセンブラ Microsoft.NET IL アセンブラ入門.NET Framework SDK 付属のアセンブラを使った開発 一般的な開発では滅多に使われる事は無いが.NET Framework SDK には ILAsm と呼ばれる 中間言語を直接記述出来るアセンブラが含まれて居る 本稿では 高水準言語を使わずに ILAsm を使ったアセンブリ言語に依る.NET Framework アプリケーション開発を説明する 初めに 実践的な開発経験の有る.NET Framework アプリケーションプログラマで有れば ILDASM を使ってプログラムを逆アセンブルしたコードを見た事が有るだろう.NET Framework アプリケーション開発は Visual Basic や C# C++/CLI 等 多くの言語を使って開発出来るが 最終的に生成されるのは標準化されて居る CIL(Common Intermediate Language) と呼ばれる中間言語で有る Microsoft Intermediate Language(MSIL) とも呼ばれ 単純に IL と略される事も有る 中間言語を含む共通言語基盤 CLI(Common Language Infrastructure) は 既に Ecma-335 や ISO/IEC JIS X3016 等で標準化されて居る為 Microsoft に依って独占されて居る技術では無い ILDASM で表示されるテキストは 中間言語に直接対応して居る CIL アセンブリ言語 (CIL Assembly Language) で書かれたコードで有る 此のアセンブリ言語を理解する事で コンパイラが生成した中間言語を読む事が出来る様に成り 高水準言語で記述したコードが 何の様な中間言語に変換されたのかを理解出来る様に成る 亦 CIL を理解する事は.NET Framework の本質にも迫る事に成る.NET Framework SDK には ILDASM に対応するアセンブラ ILASM を提供して居る ILASM は テキストで書かれた CIL コードをアセンブルして.NET Framework アプリケーションを生成する 高水準言語のコンパイラと同じ様に 実行可能ファイルや DLL ファイルを生成する事が出来 開発に実用する事も可能で有る CIL アセンブリ言語は中間言語に直接対応する唯一の言語で有る 高水準言語では 言語仕様に依る多くの制約を受けるが CIL アセンブリ言語には制約は無い.NET Framework で出来る総ての事を表現出来る唯一の言語で有り アセンブリを理解する事で 動的なコード生成等.NET Framework アプリケーションでの応用も拡がる アセンブリ言語を使った開発方法.NET Framework SDK には CIL アセンブリ言語で書かれたソースコードをアセンブルする ILASM と謂うツールが含まれて居る 最新の ILASM は.NET Framework 2.0 に含まれて居る物で有る.NET Framework 3.5 では 言語仕様に変更が加えられて居る C# や Visual Basic のコンパイラが含まれて居るが CIL その物に変更はない為 ILASM は含まれて居ない Windows Vista へのデフォルトのインストール設定では 以下のフォルダに格納されて居る C: Windows Microsoft.NET Framework v 此のフォルダ内に有る ILASM.EXE がアセンブラで有る 使い方は CSC.EXE 等と同じ様に コマン -1-

2 ド名に続いてアセンブルするソースファイルを指定する 必要に応じてオプションを指定する事も出来るが 詳細は Visual Studio に付属して居るドキュメントや ILASM のヘルプを参照され度い >ilasm ソースファイル名 CIL アセンブリ言語のソースファイルは 通常は il と謂う拡張子のテキストファイルで有る 後は 他の高水準言語と同じ様に テキストファイルにコードを書いて ILASM でアセンブルし 実行可能ファイルや DLL ファイルを生成出来る 簡単なサンプル 先ずは 何もしないプログラムを作成して ILASM を使って実行ファイルを生成出来るか何うかを試して観よう il と謂う拡張子のテキストファイルを用意する ソースファイルに記述するコードは 当然 CIL アセンブリ言語の構文に従う物でなければ成らない トークンの概念等は 他の高水準言語と大きな違いは無い トークンは ホワイトスペースや記号で区切られる為 トークンの並びが適切で 構文に従って居るので有れば改行やタブを自由に挿入出来る 細かい構文に付いては後述するので 此の場ではエントリーポイントと成るメソッドを用意する C# 言語に於ける Main メソッドに相当する物で有る エントリーポイントが無ければ EXE ファイルを生成出来ずエラーと成る Sample01 Sample01 は 何もせずに制御を返す丈のプログラムで有る 此のソースファイルを ILASM に渡すと 正しくアセンブルが行われ実行ファイルが出力される事を確認出来る 実行すると 何もせずに終了する事を期待して了うが 結果は例外が発生して終了する 実行結果 >test ハンドルされていない例外 : System.BadImageFormatException: ファイルまたはアセンブリ 'test.exe' またはその依存関係の 1 つが読み込めませんでした モジュールはアセンブリマニフェストを含んでいなければならない ファイル名 'test.exe' である 此れは 上記のコードがアセンブリマニフェストを含んで居ない為に発生する例外で有る 高水準言語で有れば コンパイラや開発環境が自動的に設定して下れて居た項目だが CIL アセンブリ言語では マニフェストを明示的に定義し無ければ成らない アセンブリを定義するには 次の様な行を加える.assembly アセンブリ名 { アセンブリ情報... アセンブリ名には 此のマニフェストに含めるアセンブリ名を指定する 其の後 { 内に任意のアセンブリ情報を指定出来る マニフェストには バージョン情報やカルチャ等を設定出来るが必須では無 -2-

3 い 此の場では空の { を指定する test と謂うアセンブリ名でマニフェストを作成するには 次の様に成る.assembly test {.NET Framework で定められて居るアセンブリで必須なのはマニフェスト丈で有る 其の為 型メタデータやコードが無くてもアセンブリを作成する事は可能で有る 実行可能ファイルの作成には エントリーポイントが必須と成る為メソッドが必要だが DLL ファイルの生成で有れば 上記の様な空のマニフェストの宣言丈でも正しくアセンブル出来る.assembly は グローバルなスコープ上で有れば何処でも記述出来るが 同一のアセンブリ内に複数のマニフェストを含める事は出来ない 通常は ファイルの先頭に記述する事に成る Sample02.assembly test { Sample02 は マニフェストを含む何もしないエントリーポイント Main メソッドを定義するコードで有る アセンブルして生成されたファイルを実行して欲しい 今度はマニフェストを含んで居る為 プログラムは何もせずに正しく終了する クラスを持たない Main メソッドが グローバルなスコープに配置されて居る事に C# プログラマは驚くかも知れないが C++/CLI では可能だった事で有る 同じ様に CIL アセンブリ言語ではグローバル変数も使う事が出来 言語的な制約を受けない 亦 Main メソッドのブロック内に と謂う記述が有る事に注目して欲しい 此れは 此のメソッドがエントリーポイントで有る事を表して居る 此処から想像出来る様に CIL アセンブリ言語ではエントリーポイントのメソッド名は任意で有る Main メソッドで有る必要は無く Start メソッドでも Init メソッドでも構わない Hello World 次に 所謂 "Hello world" サンプルを作る事にする 文字列をコンソールに表示する 最も簡単なプログラムで有る.NET Framework アプリケーション開発者で有れば 方法は既に理解して居る System.Console.WriteLine メソッドに 文字列オブジェクトを渡せば良いので有る メソッド本体に記述するコードは 計算やメソッドの呼び出し等 共通言語ランタイムが実行する実質的な命令と成る 命令は ネイティブのアセンブリ言語の仕組みと同じ様に 命令を表す整数 即ちオペコードに直接対応して居る メソッドの呼び出しには call 命令を使う call 命令 call method 但し アセンブリ言語では高水準言語の様にパラメータを渡す事は出来ない メソッドを呼び出す前にパラメータとして渡す値を読み込む必要が有る 文字列を WriteLine メソッドに渡す為に ldstr 命令 -3-

4 を使って文字列リテラルを事前に読み込む 詳しくは後述するが データはスタックに積み上げられる ldstr 命令 ldstr string string には 読み込む文字列リテラルを指定する メソッドの呼び出しやパラメータの受け渡しの詳細は 割愛する 此の場では ldstr 命令で文字列を読み込み 其の後に call 命令で WriteLine メソッドを呼び出す事で 直前に読み込んだ文字列がパラメータとして渡されると謂う流れを理解して貰えれば充分で有る Sample03.assembly extern mscorlib {.assembly test { ldstr " 流石 ILAsm!C# には出来ない事を平然と遣ってのける " 実行結果流石 ILAsm!C# には出来ない事を平然と遣ってのける Sample03 は ldstr 命令で文字列リテラルを読み込み 文字列オブジェクトをパラメータとして受け取る WriteLine メソッドを呼び出して居る CIL アセンブリ言語でも 識別子の考え方は高水準言語と同じで有る 識別子から 対象のフィールドやメソッド等のメンバにアクセス出来る System.Console クラスは mscorlib アセンブリ内に有るので ファイルの先頭で mscorlib アセンブリを参照する事を宣言して居る ディレクティブと命令 アセンブリ言語の構文は 大きくディレクティブ (directive) と命令 (instruction) に分類出来る ディレクティブは アセンブラがプログラムの構造を認識する為に用いられる物で メンバ等を宣言する為に使われる ディレクティブは必ずドットから始まるルールを持つ 此れ迄の.assembly や.method 等はディレクティブで有る 同じ様に クラスやフィールドの宣言にもディレクティブが用いられる 命令は メソッドの本体に記述する 命令は ldstr や call の様な 命令の意味を表す単純な 1 単語とパラメータで構成される 通常のアセンブリ言語と同じ様に 命令には対応するオペコードが有り アセンブリ言語の命令を理解する事で 中間言語其の物をコンパイラ無しで扱う事も不可能ではなく成る.NET Framework には オペコードから動的にメソッドを生成する機能等も有り 実行時レベルのメタプログラミング等 高次元のジック制御が可能に成るかも知れない 簡単な計算 アセンブリ言語での命令は 高水準言語の様な直観的な物では無い 多項式を一度の命令で表現する事は出来ず 加算 減算等 此れ以上分解出来ない最もシンプルな命令を並べる事で複雑なプログラムを -4-

5 記述する 高水準言語の様な気の利いたコンパイル時のチェックは行われない 不正なプログラムですら自由に書く事が出来る為 加算命令ですら状況に依っては例外を発生させる事に成る 計算は スタックに積まれて居る値に対して行われる 総てのメソッドにはデータを読み込む為のスタックが用意され 計算やデータの受け渡しにはスタックが用いられる スタックに詰める要素の数は無限では無い 各メソッド毎にスロット数を定める事が出来る スタックのスロット数は.maxstack ディレクティブを使う 此のディレクティブは メソッドのブロック内に指定する.maxstack ディレクティブ.maxstack Int32 パラメータには スタックのスロット数を指定する 此れ迄のサンプルの様に.maxstack ディレクティブを指定しなかった場合 自動的に 8 スロットが設定される 此れ迄のサンプルを ILDASM で逆アセンブルしたコードを見ると 自動的にメソッドに.maxstack が設定されて居る事を確認出来る 当然 スタックに対するデータのプッシュやポップ処理は実行時に判定される 拠って スタックが確保して居るスロット数を超えてデータをプッシュすると 実行時例外が発生する 此れは アセンブル時には判断出来ない為 開発者が管理する以外に無い 例えば スタックに適切なデータが積まれて居ない状態で WriteLine メソッドを呼び出すと 実行時に System.InvalidProgramException が発生する 文字列リテラルは ldstr で読み込んだが 数値は異なる命令でスタックに読み込む 整数リテラルや浮動小数点数リテラルをスタックに読み込むには ldc から始まる命令を使う 此の命令は ldc に続いてドット記号の後に型を表す文字が続きます 32 ビット整数の場合は ldc.i4 64 ビット整数の場合は ldc.i8 32 ビット浮動小数点数の場合は ldc.r4 64 ビット浮動小数点数の場合は ldc.r8 を使う 此の場では 32 ビット整数の例を見て観よう ldc.i4 命令 ldc.i4 num パラメータ num に スタックに読み込む値を指定する 此の命令が実行されると メソッドのスタックに値がプッシュされ 他の命令で値が用いられるとポップされる 前述のメソッドの呼び出し等でも メソッドがパラメータを受け取る場合は スタックに積まれて居る値が順にポップされる 例えば 次の様に連続してメソッドを呼び出す事も可能で有る ldc.i4 10 ldc.i4 100 call void [mscorlib]system.console::writeline(int32) //100 call void [mscorlib]system.console::writeline(int32) //10 上記のコードは 以下のコードと同じ振る舞いで有る ldc.i4 100 call void [mscorlib]system.console::writeline(int32) //100 ldc.i4 10 call void [mscorlib]system.console::writeline(int32) //10 通常 C# 言語コンパイラ等で出力した中間言語は 後者のコードの様にメソッドを呼び出す直前に 必要な分丈パラメータをスタックに読み込む形に成るだろう 処が アセンブリ言語は 使うと予想され -5-

6 るデータを事前にスタックに読み込み 其の後 連続してメソッドを呼び出すと謂う変則的なコードを書く事が出来る 多くの場合 中間言語を知り尽くした技術者に依って開発されたコンパイラが生成するコードの方が効率的で パフォーマンスに於いても優れた結果が得られるだろう 併し アセンブリ言語ならば高水準言語では調整が難しい細かな命令に迄手が出せる 極限に迄中間言語のサイズを落としたい場合等 特定の要求に効果を発揮するかも知れない 計算は スタックに読み込まれて居る値を使って行われる 加算演算の場合は add 命令を使う 此の命令はスタックから加算する 2 つの値をポップし 加算した結果をスタックにプッシュする add 命令 add add 命令自体は パラメータを受け取らない add 命令から 他の四則演算の方法も容易に予測出来る 減算は sub 命令 乗算は mul 命令 除算は div 命令 剰余は rem 命令を使う 計算方法は同じで 各演算命令はスタックから計算する値をポップし 結果をプッシュする Sample04.assembly extern mscorlib {.assembly test {.maxstack 2 ldc.i4 1 ldc.i4 2 add call void [mscorlib]system.console::writeline(int32) ldc.i4 5 ldc.i4 3 sub call void [mscorlib]system.console::writeline(int32) ldc.i4 5 ldc.i4 3 mul call void [mscorlib]system.console::writeline(int32) ldc.i4 10 ldc.i4 2 div call void [mscorlib]system.console::writeline(int32) ldc.i4 3 ldc.i4 2 rem -6-

7 call void [mscorlib]system.console::writeline(int32) 実行結果 Sample04 は 適当な値をスタックに読み込み 各種演算を行うプログラムで有る 演算の結果はスタックに戻されるので 其れを其の儘 WriteLine メソッドで表示して居る 此の様な 整数リテラルを計算するプログラムを高水準言語のコンパイラが生成する事は無い 整数リテラルの式はコンパイル時に計算出来る為 最適化されて了う 実際に C# 言語で作成した次の様な文を逆アセンブルすると 事前に計算されて居る事を確認出来る System.Console.WriteLine(1 + 2); 上記のコードは Sample04 の様な add 命令を出力する事は無い 結果を逆アセンブルすると 整数リテラルが事前に計算され 単純に 3 と謂う値を読み込んで WriteLine メソッドで出力するコードに置き換えられる 因みに 0~8 迄の値の読み込みには ldc.i4.0~idc.i4.8 と謂う専用の命令が割り当てられて居る 亦 -1 も ldc.i4.m1 と謂う命令で読み込めます 此等の命令は オペコード丈で構成される為 idc.i4 命令よりもサイズが小さく効率的で有る 通常 -1~8 迄の定数をスタックに読み込みたい場合は 此等専用の命令を使い 其れ以外の値を読み込む場合に ldc.i4 を使う 制御 次に 簡単な制御方法に付いて説明する プログラムの流れ制御は 高水準言語の様な構造的な物ではないので 命令単位に自由にジャンプ出来る 所謂 if 文の様な分岐も可能だし goto 文の様な無条件ジャンプも可能で有る 無条件ジャンプは 強制的に実行するコードを指定の位置に移動する br 命令を使う br 命令 br target target には 移動先のコードのアドレスを指定する 実際には メソッド内のコードのオフセットを表す 4 バイトの整数が保存されるが アセンブリ言語内では命令に名前を付けて 識別子で指定出来る 命令には コードラベルと呼ばれる名前を付ける事が出来る コードラベルは次の様に指定する コードラベル Id: 此のコードラベルの直後が 移動先の対象命令と成る コードラベルの Id に指定した識別子を br 命 -7-

8 令の target に設定する事で 強制的にラベルの命令迄移動する 此の命令を使う事で 同一メソッド内の任意の命令にジャンプ出来る Sample05.assembly extern mscorlib {.assembly test { ldstr " さぁ 始めよう " br target ldstr " 行くぞ " target: ldstr " よし " 実行結果さぁ 始めようよし Sample05 は メソッドの途中で br 命令を使って 途中の幾つかの命令を省略するプログラムで有る コード内では 3 回 WriteLine メソッドの呼び出しが行われて居るが 中間の呼び出しは実行されない br 命令が実行された時点で 制御は target ラベルの ldstr に移動する 条件分岐には 計算と同じ様にスタックに読み込まれて居る値が使われる 分岐の方法は 値が 0 以外の true を表す場合に実行される brtrue 命令と 値が 0 即ち false や null の場合に実行される brfalse 命令が有る brtrue 命令 brtrue target 書式は br 命令と同じで有る 此の命令を実行すると スタックに読み込まれて居る値がポップされ 其の値が 0 以外で有れば target に分岐する null で無ければ分岐すると謂う意味の別名で brinst 命令も用意されて居る brtrue も brinst もオペコードは同じなので 単純な別名で有る 孰れを使っても構わないが 通常は調べる対象が値型で有れば brtrue 参照型で有れば brinst を使った方が解り易いだろう 値が 0 で有れば分岐する brfalse 命令も 仕組みは同じで有る brfalse 命令 brfalse target -8-

9 矢張り スタックに読み込まれて居る値がポップされ 其の値が 0 で有れば target に分岐する 同一の意味を持つ別名の命令で brnull 及び brzero も用意されて居るが 矢張りオペコードは同じで有る brtrue 又は brfalse 孰れかの命令を使う事で 高水準言語に於ける if-else 文の処理が実現出来る Sample06.assembly extern mscorlib {.assembly test { ldc.i4.1 brfalse else ldstr " スタックは true です " br endif else: ldstr " スタックは false です " endif: ldstr " 分岐処理を終了する " 実行結果スタックは true です分岐処理を終了する Sample06 は 最初の ldc.i4.1 命令でスタックに読み込んだ値を使って分岐処理を行い true か false かを表す文字列を出力する 命令には brfalse を使って居るので スタックの値が true で有れば其の儘逐次に実行され 然うで無ければ else ラベル迄ジャンプする brfalse でジャンプしなかった場合 其の儘コードが続けて実行される else ラベル以降が其の儘実行されない様に br 命令で endif 迄ジャンプして居る 因みに.NET Framework SDK 付属の C# コンパイラで bool 型の変数を if 文に与えた場合 変数の値と 0 をスタックに読み込んだ後 値が等しいか何うかを調べる ceq 命令を使って居る 其の後 brtrue 命令で変数の値が 0 即ち false で有れば else 部分にジャンプし 然うで無ければ実行を続けると謂う流れに成って居た 本稿では解説して居ない為割愛するが 変数を使う事で反復処理も同じ原理で実現出来る 変数に繰り返す回数を代入し 変数の値をスタックに読み込んで 0 か何うかを調べ 0 で無ければ処理を実行して -9-

10 値をデクリメントする 最後に 処理の冒頭にジャンプする事で 変数の値が 0 に成る迄処理が繰り返される 最後に 扨て 本稿ではアセンブリ言語の基本的な構造と命令に付いて説明した 本稿の内容に加えて クラスやメソッド等を宣言するディレクティブを使う事で 他の高水準言語と同じ様に 構造的にコンポーネントを開発出来る ディレクティブに付いては割愛したが 其の多くは Visual Basic や C# の経験が有れば 直観的に理解出来る物だろう ILDASM を使って逆アセンブルしたコードを解析して コンパイラが何の様な中間言語を生成して居るのかを調べるのも面白いと思う アセンブリ言語を実践の開発現場で実用する事は 生産性や保守性の面で困難かも知れないが 此れを理解する事で.NET Framework の本質が観えて来る 若し Visual Basic チームと C# チームが対立し 何うにもプロジェクトが纏まらない時は アセンブリ言語を叩き込む事で仲良く成るかも知れない 少数派の C++/CLI チームが親の敵の様にマネージテンプレートを使って我が道を突き進んで居る時も 逆アセンブルする事で 何の様なコードが生成されて居るのか調べられる 孰れにしても アセンブリ言語を理解する事で 斯う謂った小回りが利く事は多少成りのメリットに成る筈で有る 更に 特殊な開発支援ツールや 実行時の型解析 ロジックの生成等にも CIL の知識が必要に成る 動的な中間言語の生成は 間も無く登場する予定の動的言語ランタイムや.NET Framework 3.5 で追加された式木の基礎にも成って居る重要なテクニックで有る アイデア次第で面白いプログラムが書けるかも知れない 是非試して観て欲しい 参考 Inside Microsoft.NET IL Assembler(Serge Lidin 著 Microsoft Pr 2002 年 2 月 ) Standard ECMA-335 Common Language Infrastructure (CLI)(Ecma International)