Dalvik VM内でのJavaとCの友情はどれほど強力ですか？

この記事では、AndroidコードとDalvik VMでの実行を検証する際に、手順を非常に詳細に説明しようとしました。 質問に対する答えを知りたいと思いました。

• Cによって生成されたコードはどのように見えますか？ （ARMの位置から）
• Javaによって生成されたコードはどのように見えますか？
• コードはどのように、どこで実行されますか？

したがって、この記事は3つのパートに分かれています。



私はそのような質問を投げかけてそれらを研究するように思えます-アンドロイドはすでにかかとを踏んでいて、それを知らずにそのお気に入りのツールの1つ（たとえばC）が正しくないので、コードのその後の執筆の重要なポイントです。





それ以前は、仮想マシンを実際には分析していませんでしたが、今はDalvik VMに興味があります。 したがって、説明全体がこのVMに適用され、ナレーションを観察できます。ナレーションのコースは数回変更されます。

エントリー

この記事を理解するには、ARMアーキテクチャのアセンブラーの基本的な知識が必要です。 これを理解するための記事にはほとんど情報がありませんが、読者がこれを知らないという事実に重点が置かれています。 したがって、「あなた自身の言葉で」多くの説明がありますが、それ以上はありません。



また、Androidアプリケーションを最初から作成するスキルを持っている必要があります（ディレクトリ構造とメインファイルを知っている）。



各記事の結果を見て、読むべきかどうかを確認することもできます。



3つの部分はすべて荷重が大きく異なり、強度がほぼ同じです。 たとえば、3番目の部分に移動すると、最初の部分に関連して2番目の部分と2番目の部分のように複雑なように見えます。 そのため、アイテムを所有していない場合は注意してください。最終的には負荷が大きくなる可能性があります。

誰が記事に興味を持ちますか

冒険者だけ。



優れた開発者は、彼がこれを知らない場合、簡単に見つけます（優れた開発者に対する私の理解がそれほど高くないことを望みます）が、何かを始めて試してみたいが、方法を知らない人は、彼にとって非常に難しいでしょう。



Dalvik VMのような鬱denseとした森の中で、自分自身に質問して答えを見つけることは現実的であり、同じ大胆な行動をとることを決めた人にこの方法を示したいと思いました。

最初の目標

私の主なタスクは、Cコードを比較することです。

int sum(int a, int b) { return a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じJavaコードの場合：

  public class Summator { int sum(int a, int b) { return a + b; } static int staticSum(int a, int b) { return a + b; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

  public class NativeSummator { native int sum(int a, int b); static native int staticSum(int a, int b); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかの仮定がありますが、私は本当にそれが実際にどのように起こるかを見たいです。

予備知識

ここで、JNIを介して、JavaでのCコードの統合がどのように見えるかを思い出します。



Javaコードで外部（ネイティブ）関数を使用するには、nativeキーワードが使用されます。

 package com.m039.study; public class Summator { native int sum(int a, int b); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、Cコードは次のようになります。

 int Java_com_m039_study_Summator_sum(JNIEnv* env, jobject thiz, int a, int b) { return a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Javaが関数を表示するには、特定のルール（メモリから与えられた）に従って構成する必要があります。

• 名前はjavaで始まります
• 次のパスが含まれます：モジュール+クラス名+関数名
• 2つの追加の引数が関数に渡されます：環境へのポインターとオブジェクトまたはクラスへの構造（メソッドが静的な場合）

コンパイルには、 ndk-build



コマンドが使用されます。 このコマンドは、C（またはC ++）ファイルが./jniディレクトリにあることを想定しています。 ディレクトリにはAndroid.mkファイルが含まれている必要があり、Application.mkである場合があります。



コンパイル後、libNAME.soライブラリは./libs/armebiディレクトリに作成されますが、armebiは異なる場合があります。



より詳細な手順が必要な場合は、別のドキュメントを参照する必要があります。 NDKに添付されているドキュメントとサンプルのカタログをご覧ください 。

パートI. Cによって生成されたコードはどのように見えますか？

質問：Cコードは正確に何をしますか？



原則として、これは理解できますが、ARMアーキテクチャの観点から見ると、 ほとんどすべてのモバイルデバイスがこの特定のアーキテクチャを使用していますか？



これを理解するには、Cコードがアセンブラー（生）形式でどのように見えるかを理解する必要があります。

分解する

主な質問は、CとJavaの相互作用です。これに基づいて、5つの例を選択しました。



1.標準：

 int sum(int a, int b) { return a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2. JNIを介したバインド（静的ではない）：

  int Java_com_m039_study_Summator_sum(JNIEnv* env, jobject thiz, int a, int b) { return a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3. JNI経由のバインディング（静的）：

  int Java_com_m039_study_StaticSummator_sum(JNIEnv* env, jclass thiz, int a, int b) { return a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

4. JNIを介したバインド（静的ではなく、関数を使用）：

  int Java_com_m039_study_Summator_sum(JNIEnv* env, jobject thiz, int a, int b) { return sum(a, b); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

5. JNIを介したバインド（静的、関数を使用）：

  int Java_com_m039_study_StaticSummator_sum(JNIEnv* env, jclass thiz, int a, int b) { return sum(a, b); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少し考えてみましょう。 4と5は、完全ではないにしても、ほとんど似ているように思えます。 1-3は、送信されるパラメータが異なる必要があります。 これは私が確認したいものです。

ビルドシステム

Androidアプリケーションのビルドシステムは非常に単純化されており、Androidのコンパイル済みコードをチェックするなどの目的で、コンパイルフラグを知る必要があります。 特に、最適化フラグ。



Application.mkファイルでは、 APP_OPTIM



変数を変更して、リリースまたはデバッグの2つの値のいずれかに割り当てることができます。



なぜなら この記事の目的は、2つの言語の統合を比較することであり、1つの言語をよく理解することではありません。その後、推論を簡単にするために、値 'debug'を使用します。 これにより、理解が深まり、エラーが発生する可能性が低くなります（この記事を書く機会が増えます）が、とにかく、「リリース」モードのコードの違いを調べる必要があります。



今、もう少し詳細。



APPLICATION-MK.htmlファイルには、 APP_OPTIM



フラグのAPP_OPTIM



説明されており、 アプリケーションタグの属性をandroid:debuggable="true"



変更でき、 APP_OPTIM



変数APP_OPTIM



'debug'に設定APP_OPTIM



れることも示されています。 属性がfalseに設定されている場合、 APP_OPTIM



'release'に割り当てられます。



したがって、 android:debuggable



属性がAndroidManifest.xmlで「true」にandroid:debuggable



ているとさらに想定されています。



また、変数APP_OPTIM



を使用するときにコンパイラーに渡される値を逃すことはできません。同じファイルで以下のように表示されます 。

 ifeq ($(APP_OPTIM),debug) APP_CFLAGS := -O0 -g $(APP_CFLAGS) else APP_CFLAGS := -O2 -DNDEBUG -g $(APP_CFLAGS) endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、5つのオプションすべてを検討し始めます。

「デバッグ」モード

注 ：すべてのリストは、コマンドarm-linux-androideabi-objdump -d " "



取得されましたarm-linux-androideabi-objdump -d " "

オプション1

 00000804 <sum>: 804: b082 sub sp, #8 806: 9001 str r0, [sp, #4] 808: 9100 str r1, [sp, #0] 80a: 9a01 ldr r2, [sp, #4] 80c: 9b00 ldr r3, [sp, #0] 80e: 18d3 adds r3, r2, r3 810: 1c18 adds r0, r3, #0 812: b002 add sp, #8 814: 4770 bx lr 816: 46c0 nop (mov r8, r8)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリストには多くの余分なものがありますが、これはすべて呼び出し規約、より具体的にはARM呼び出し規約のためです。



私はこの例を翻訳します：

-04：2つのローカル変数用にメモリを予約します。

-06-08：関数に渡された引数を保存します。

-0a-0c：同じ引数が他のレジスタr2およびr3にそれぞれ渡されます。

-0e：r3 = r2 + r3と同等

-10：結果をレジスタr0に保存します

-12：スタックポインターを初期状態に戻す

-14：元の場所に戻る

-16：nopコマンドを使用してファイル内の関数を整列する



追加 ：2つのポイントは明確ではありませんでした：サフィックスsとコマンドbx。 最初は、実行時にステータスフラグも更新されることを意味します。 2番目はthumbコマンドで、blコマンドと同等です。



コードを噛んだ後、さらに多くのものがあることが明らかになりました。 もちろん、最適化を使用する場合、そのようなものはありませんでした。



このリストには、引数が関数にどのように渡され、主要部分がどのように実行されるかを示す2つのポイントしかありません。



引数はレジスタを介して渡され、メイン部分にはコマンドが1つだけ含まれます。 ここから、コードadds r0, r1, r2; bx lr



することを確認できましたadds r0, r1, r2; bx lr



adds r0, r1, r2; bx lr



は存在する権利があります。



ただし、このようなコードが完成したアプリケーションにあるとは言えません（誰かが「デバッグ」バージョンを市場にリリースすることを決定しない限り）。 そして、Javaではすべてが悪化しているという仮定がありますが、私はそれを確認したいと思います。 したがって、残りのリストをすばやく確認する必要があります。

オプション2

 000007ec <Java_com_m039_study_Summator_sum>: 7ec: b084 sub sp, #16 7ee: 9003 str r0, [sp, #12] 7f0: 9102 str r1, [sp, #8] 7f2: 9201 str r2, [sp, #4] 7f4: 9300 str r3, [sp, #0] 7f6: 9a01 ldr r2, [sp, #4] 7f8: 9b00 ldr r3, [sp, #0] 7fa: 18d3 adds r3, r2, r3 7fc: 1c18 adds r0, r3, #0 7fe: b004 add sp, #16 800: 4770 bx lr 802: 46c0 nop (mov r8, r8)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

はい、はい、同じこと、そして予想どおり、引数の数だけが増えました。 そして、何回の不必要な操作、恐怖。 しかし同時に、最適化されたバージョンを見たいという欲求ははるかに大きくなります。



注 ：多くのJNI関数（追加の引数が渡される）を使用することは、単純な関数（より少ない引数が渡される）よりも悪いという仮定が確認されています。 （今、この記事を書き直しているとき、この声明は非常に素朴に聞こえます）

オプション3

 00000850 <Java_com_m039_study_StaticSummator_sum>: 850: b084 sub sp, #16 852: 9003 str r0, [sp, #12] 854: 9102 str r1, [sp, #8] 856: 9201 str r2, [sp, #4] 858: 9300 str r3, [sp, #0] 85a: 9a01 ldr r2, [sp, #4] 85c: 9b00 ldr r3, [sp, #0] 85e: 18d3 adds r3, r2, r3 860: 1c18 adds r0, r3, #0 862: b004 add sp, #16 864: 4770 bx lr 866: 46c0 nop (mov r8, r8)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

仮定は正当化され、コードはオプション2と同じです。

オプション4

 000008e0 <Java_com_m039_study_Summator_sum>: 8e0: b500 push {lr} 8e2: b085 sub sp, #20 8e4: 9003 str r0, [sp, #12] 8e6: 9102 str r1, [sp, #8] 8e8: 9201 str r2, [sp, #4] 8ea: 9300 str r3, [sp, #0] 8ec: 9a01 ldr r2, [sp, #4] 8ee: 9b00 ldr r3, [sp, #0] 8f0: 1c10 adds r0, r2, #0 8f2: 1c19 adds r1, r3, #0 8f4: f7ff ffde bl 8b4 <sum> 8f8: 1c03 adds r3, r0, #0 8fa: 1c18 adds r0, r3, #0 8fc: b005 add sp, #20 8fe: bd00 pop {pc}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

なぜこのオプションを検討する必要があるのですか？ JNI関数ですべてを書く方が良いと思った場合に備えて。 一方、実際には、JNIをより複雑な設計のラッパーとして使用することをお勧めします。 また、小さなC関数では、何でもできます。 （ 注 ：この記事を書いた後、この声明はすでに私には明らかなようです）



このコードはもう少し複雑です：

-e0：返信先アドレスを保存します

-e2：ローカル変数用にメモリを予約します

-e4-ea：引数をローカル変数に保存します

-ec-ee：ローカル変数の値を取得します

-f0-f2：関数呼び出しのためにレジスタの値を準備します

-f4：関数呼び出し自体

-f8-fa：結果をレジスタに保存し、戻り値のレジスタに書き込みます

-fc：スタックポインターを初期位置に戻します

-fe：呼び出した場所に移動します



レジスタlrがbl命令を介して書き換えられることを考えると、文字列「e0」は戻りアドレスを格納するために使用されます。



ご覧のとおり、余分なコードがたくさんあります。 そのようなコードには存在する権利があると思います：

 push {lr} sub sp, #20 adds r0, r2, #0 adds r1, r3, #0 bl 8b4 <sum> add sp, #20 pop {pc}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オプション5

検討する価値はないと思います。

リリースモードで

最適化されたバージョンに含まれるコードについての推測をテストしたいと思います。

オプション1

 0000894 <sum>: 894: 1808 adds r0, r1, r0 896: 4770 bx lr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オプション2

 00000890 <Java_com_m039_study_Summator_sum>: 890: 1898 adds r0, r3, r2 892: 4770 bx lr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オプション3

 00000898 <Java_com_m039_study_StaticSummator_SUM>: 898: 1898 adds r0, r3, r2 89a: 4770 bx lr
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オプション4

 0000089c <Java_com_m039_study_Summator_SUM3>: 89c: b510 push {r4, lr} 89e: 1c10 adds r0, r2, #0 8a0: 1c19 adds r1, r3, #0 8a2: f7ff fff7 bl 894 <sum> 8a6: bd10 pop {r4, pc}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

印象

私は少し驚いています。 その前に一致するはずだったすべてのもの。 最適化されたコードは優れており、私が自分で書き込もうとしたコードに非常に近いものです。

パートI.まとめ

このパートでは、おそらくARMでのアセンブラーを紹介します。 他の言語構成要素を分析して理解することもできます。 また、あなたの推測に驚くかもしれません。



しかし、最も重要なことは、あなたがアンドロイド開発者であれば、デフォルトのコンパイル設定がどのように使用され、必要なときにどこを見るべきかを理解できるようになりました。



最初は、JavaコードよりもCコードの方がどれだけ優れているかを知りたいと思いました。 最初は記事を書きましたが、この結果を書いています。 今のところ、Cの問題を解決することがいかにエレガントで、分解された形でどれだけコンパクトになったかに注意を払うことができます。 Javaオペコードでは、これも見られますが、すでに少なくなっています。 そして、オペコードがCと混在している3番目の記事では、これは実際にはありません。



そして今、Javaオペコードについて少しだけ説明します。

パートII Javaによって生成されたコードはどのように見えますか？

最初に、JVM（またはDalvik VM）がどのように機能するかを理解する必要があります。 これを行うには、Dalvik VMのバイトコードファイルである* .dexファイルを逆アセンブルする必要があります。



Summatorクラスはどのようになりますか（元の目標を参照）？ これを行うには、プログラムdexdump -d classes.dex



設定します。 コマンドが発行したもの：

  #5 : (in Lcom/m039/study/Summator;) name : 'sum' type : '(II)I' access : 0x0000 () code - registers : 4 ins : 3 outs : 0 insns size : 3 16-bit code units 00226c: |[00226c] com.m039.study.Summator.sum:(II)I 00227c: 9000 0203 |0000: add-int v0, v2, v3 002280: 0f00 |0002: return v0 catches : (none) positions : 0x0000 line=73 locals : 0x0000 - 0x0003 reg=1 this com/m039/study/Summator; 0x0000 - 0x0003 reg=2 a I 0x0000 - 0x0003 reg=3 b I
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

  name : 'staticSum' type : '(II)I' access : 0x0008 (STATIC) code - registers : 3 ins : 2 outs : 0 insns size : 3 16-bit code units 002100: |[002100] com.m039.study.Summator.staticSum:(II)I 002110: 9000 0102 |0000: add-int v0, v1, v2 002114: 0f00 |0002: return v0 catches : (none) positions : 0x0000 line=77 locals : 0x0000 - 0x0003 reg=1 a I 0x0000 - 0x0003 reg=2 b I
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここではadd-int v0, v1, v2



、およびオペコード「9000 0102」の値を考慮する必要があります。 これで、内部からこれらのオペコードがどのように見えるかに進むことができます。

監視するオペコードは何ですか？

ARMアーキテクチャにもっと興味があります。 このアーキテクチャはデフォルトで使用されるため、オペコードが適切です。 しかし、多くのARMがあり、デフォルトでどれが使用されますか？



これを行うには、Application.mkドキュメント、より具体的には変数APP_ABIの説明を参照してください。 デフォルトではarmv5teが使用されると記載されています。 ここで探索します！

どこから視聴を始めますか？

オペコード自体はarmv5teディレクトリにあります。 このディレクトリにあるファイルを検討するのは正しいでしょうが、私はそれをまったく正しくない方法でやりたいと思っていましたが、既に生成されたファイルを検討するためにも機能します。 より具体的には、 InterpAsm-armv5te.S。File 。 とても面白くて実用的です。

ドキュメント

すべての主要なドキュメントはdocsディレクトリにありますが、必要に応じて、生のHTMLよりも読みやすい形式へのリンクを提供します。

追加オペコードの検査（0x90）

オペコード0x90 、そのコードを考えてみましょう：

 .L_OP_ADD_INT: /* 0x90 */ /* File: armv5te/OP_ADD_INT.S */ /* File: armv5te/binop.S */ /* * Generic 32-bit binary operation. Provide an "instr" line that * specifies an instruction that performs "result = r0 op r1". * This could be an ARM instruction or a function call. (If the result * comes back in a register other than r0, you can override "result".) * * If "chkzero" is set to 1, we perform a divide-by-zero check on * vCC (r1). Useful for integer division and modulus. Note that we * *don't* check for (INT_MIN / -1) here, because the ARM math lib * handles it correctly. * * For: add-int, sub-int, mul-int, div-int, rem-int, and-int, or-int, * xor-int, shl-int, shr-int, ushr-int, add-float, sub-float, * mul-float, div-float, rem-float */ /* binop vAA, vBB, vCC */ FETCH(r0, 1) @ r0<- CCBB mov r9, rINST, lsr #8 @ r9<- AA mov r3, r0, lsr #8 @ r3<- CC and r2, r0, #255 @ r2<- BB GET_VREG(r1, r3) @ r1<- vCC GET_VREG(r0, r2) @ r0<- vBB .if 0 cmp r1, #0 @ is second operand zero? beq common_errDivideByZero .endif FETCH_ADVANCE_INST(2) @ advance rPC, load rINST @ optional op; may set condition codes add r0, r0, r1 @ r0<- op, r0-r3 changed GET_INST_OPCODE(ip) @ extract opcode from rINST SET_VREG(r0, r9) @ vAA<- r0 GOTO_OPCODE(ip) @ jump to next instruction /* 11-14 instructions */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コメントを見ると、すべてが明確になりますが、コード内でこれらのコメントを自分で見たいと思います。 したがって、このコードの一部をさらに分析します。



オペコード0x90は加算命令に対応し、その形式は23xです。 これは、命令サイズが2バイトであり、3つのレジスタを使用することを意味します。「x」は、これ以外に何もないことを意味します。



したがって、このオペコードのコードは、これらの3つのレジスタを抽出し、23x形式で送信し、加算に使用する必要があります。 しかし、ここではすべてがそれほど単純ではないことがわかります。 レジスタの接頭辞「v」、たとえば「vCC」は、仮想を意味します。 そして、オペコードがレジスタ番号を渡し、命令が指定されたレジスタに含まれる値を取得することがわかります。 （ 注 ：レジスターには常に接頭辞「v」が付いているわけではありません）



次のようになります。

-オペコードがあります：00 | 90 02 | 01（AA | op CC | BB）*

-90はオペコードを追加することを意味します

-レジスタ番号を抽出r9 = 0、r2 = 1、r3 = 2

-レジスタの内容を抽出しますr1 = REG（r3）、r0 = REG（r2）**

-「add r0、r0、r1」という命令を実行します

-戻り値REG（r9）= r0を保存します



*認識を容易にするために、ドキュメントと同様に追加|

** REG-擬似コードです



このオペコードには、別のオペコードに切り替えるために必要なコマンドも含まれています。 少し分析するので、今は注意を払ってはいけません。



そして今、それはすべてアセンブラーまたはより厳しい説明でどのように見えますか：

1. FETCH （r0、1）。 このオペコード（0x90）は、r4とr5に対応する2つのレジスタrPCとrINST（同上）を使用します。 少し下を見ると、rINST（ FETCH_INST ）がrPCの値であることがわかります。 したがって、rINSTはFETCHコマンドの値（rINST、0）と等しいと言えます。



2.レジスタ番号は、標準の方法を使用して取得されます。 （写真を参照）



3. GET_VREG （r1、r3）。 新しいrFPレジスタが表示されます。 このレジスタは、ローカル変数と引数のメモリ領域を指します。 つまり これにより、引数の値を抽出し、戻り値を書き込むことができます。 VMの内部レジスターへのポインターとして表すことができます。



4. .if 0 ... .endifはわかりにくいですが、InterpAsm-armv5te.S！ファイルで調査を開始したためです。 binop.Sファイルを見ると、このオペコードの2番目の引数であるゼロのチェックが無効になっていることが明らかになります。



5. FETCH_ADVANCE_INST（2）の詳細



6.追加が進行中です



7. GET_INST_OPCODE（ip）についてさらに説明します。



8. SET_VREG （r0、r9）は、戻り値を対応するレジスタに書き込みます。このレジスタの番号はr0で指定されます。



9.後で説明するGOTO_OPCODE（ip）



私は視覚的な（私は願っています）写真を描きました：





オペコードは同じアセンブラコードに似ている（「r0、r1、r0を追加する」）だけで、仮想レジスタの処理と次のオペコードへの移動という2つの追加だけであると結論付けることができます。

審査前の部分

仮想レジスタの処理が考慮されました。 オペコードの他のチームが何をしているのかを理解する必要もあります。彼らがあまりにも遠くないことを願っています。 たとえば、rFPやrPCなどのレジスタの値が初期化される場合。 興味深いことではありますが、目標からの強い分岐です。



次に、残りのコマンドを検討します。

1. FETCH_ADVANCE_INST （2）次のオペコードがrINSTレジスタに書き込まれます

2. ipレジスタのGET_INST_OPCODE （ip）にオペコード番号を入力します（すでに次）

3. GOTO_OPCODE （ip）次のオペコードのコードに移動します



これら3つのコマンドでは、rIBASEレジスタが表示されます。 番号が0x00のオペコードかどうかを確認する必要がありますか？ どうやらそうだ。 はい、そうです。 多くの場合、コードには次の行があります。

 adr rIBASE, dvmAsmInstructionStart @ set rIBASE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、 dvmAsmInstructionStartの値は.L_OP_NOPです。 OP_NOPコードはどうですか？ 本当に0x00です。

考慮しなかったが、私はしたい

このセクションでは、他の初期（rPC、rFP）レジスタの内容のみを考慮しませんでした。 おそらく私たちはそれらをさらに検討します。 なぜそれが「可能」なのか、これまでのところrPCではなくrFPが大きな価値があるからです。

追加オペコードを調べる（正しいバージョン）

オペコードの検査方法は完全に正しいとは思えませんでしたが、私にとってはより快適に思えました。 しかし、今度はこれをどのように改善できるか、つまりarm5vteフォルダー内のファイルはどのように構成されているのかを見てみましょう。



これを行うには、 README.txtドキュメントを参照してください。



少し驚いていますが、研究に使用した方法はREADME.txtファイルの観点からは正しいものでした。 引用はここにあります：



「インタープリターに慣れる最善の方法は、armv5teのさまざまなコンポーネントを調べるのではなく、out / InterpC-portstd.cなどのoutディレクトリで生成されたファイルを調べることです。 」



ここで、例として、ファイルOP_ADD_INS.Sを考えます。

 %verify "executed" %include "armv5te/binop.S" {"instr":"add r0, r0, r1"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、このファイルが条件付きでbinop.Sファイルに置き換えられ、$ instrの値にadd r0, r0, r1



がadd r0, r0, r1



されることadd r0, r0, r1



意味します。



binop.Sファイルを検討する必要があります。

 %default {"preinstr":"", "result":"r0", "chkzero":"0"} /* * Generic 32-bit binary operation. Provide an "instr" line that * specifies an instruction that performs "result = r0 op r1". * This could be an ARM instruction or a function call. (If the result * comes back in a register other than r0, you can override "result".) * * If "chkzero" is set to 1, we perform a divide-by-zero check on * vCC (r1). Useful for integer division and modulus. Note that we * *don't* check for (INT_MIN / -1) here, because the ARM math lib * handles it correctly. * * For: add-int, sub-int, mul-int, div-int, rem-int, and-int, or-int, * xor-int, shl-int, shr-int, ushr-int, add-float, sub-float, * mul-float, div-float, rem-float */ /* binop vAA, vBB, vCC */ FETCH(r0, 1) @ r0<- CCBB mov r9, rINST, lsr #8 @ r9<- AA mov r3, r0, lsr #8 @ r3<- CC and r2, r0, #255 @ r2<- BB GET_VREG(r1, r3) @ r1<- vCC GET_VREG(r0, r2) @ r0<- vBB .if $chkzero cmp r1, #0 @ is second operand zero? beq common_errDivideByZero .endif FETCH_ADVANCE_INST(2) @ advance rPC, load rINST $preinstr @ optional op; may set condition codes $instr @ $result<- op, r0-r3 changed GET_INST_OPCODE(ip) @ extract opcode from rINST SET_VREG($result, r9) @ vAA<- $result GOTO_OPCODE(ip) @ jump to next instruction
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、コードは以前と非常によく似ています。 今しか理解できない瞬間は残っていません。 たとえば、「@ optional op ..」というコメントがありましたが、その理由は明らかではありません。 今では明らかです。



このオペコードを分解することには意味がありません。すべてがすでに考慮されています。 ここで、最も重要な質問にすばやく進む必要があります。ネイティブ関数と非ネイティブ関数の引数はどのように取り込まれますか？

パートII まとめ

それはすでに最初の部分とは異なるレベルでした、私は多くを学び、覚えていなければなりませんでしたが、オペコードの構造は明確になりました！ 楽しめます。 はい、これに喜びを感じることほど大きな意味はありません。 ただし、同時に、すでにオペコードを作成できます。



この部分から、ファイルを生成するために使用されるアーキテクチャを学習できます。 適切なオペコードを見つける場所と方法。



また、多くの質問があるかもしれません。開発者のDalvik VMのプレゼンテーションを見ることをお勧めします。このプレゼンテーションでは、GOTO_OPCODEなどのコマンドがどのように使用されているか、またはバイトコードキューがどのように編成されているかを非常によく示しています。



目標についてすぐに結論を出すつもりはありません。すべての結論は記事の最後になります。そして今、Dalvik VMの内部に飛び込んで、このコードが実行される場所を理解することを提案しますが、レベルがさらに高くなると警告しますが、挿入するコードは少なくします。

パートIII。コードはどのように、どこで実行されますか？

第3部では、Dalvik VMで関数を抽出するプロセスについて説明します。以前の知識は大いに役立ちますが、飛躍は第1部と第2部の間と同じであると仮定するのは怖いです。さあ始めましょう！



注：すぐにリンクをたどるのではなく、最初に読むことをお勧めします。そのため、資料は徐々に表示され、混乱する可能性は低くなります。

分解する

オペコードがどのように読み込まれるかを理解する必要があります。そのため、このようなセクショナルコードを見ていきます。

  public class Summator { void test() { sum(44, 43); staticSum(42, 41); nSum(44, 43); nStaticSum(42, 41); } int sum(int a, int b) { return a + b; } static int staticSum(int a, int b) { return a + b; } native int nSum(int a, int b); native static int nStaticSum(int a, int b); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

  name : 'test' type : '()V' access : 0x0000 () code - registers : 5 ins : 1 outs : 3 insns size : 21 16-bit code units outs : 3 insns size : 21 16-bit code units 0022a8: |[0022a8] com.m039.study.Summator.test:()V 0022b8: 1303 2c00 |0000: const/16 v3, #int 44 // #2c 0022bc: 1302 2b00 |0002: const/16 v2, #int 43 // #2b 0022c0: 1301 2a00 |0004: const/16 v1, #int 42 // #2a 0022c4: 1300 2900 |0006: const/16 v0, #int 41 // #29 0022c8: 6e30 2e00 3402|0008: invoke-virtual {v4, v3, v2}, Lcom/m039/study/Summator;.sum:(II)I // method@002e 0022ce: 7120 2d00 0100|000b: invoke-static {v1, v0}, Lcom/m039/study/Summator;.staticSum:(II)I // method@002d 0022d4: 6e30 2600 3402|000e: invoke-virtual {v4, v3, v2}, Lcom/m039/study/Summator;.nSum:(II)I // method@0026 0022da: 7120 2500 0100|0011: invoke-static {v1, v0}, Lcom/m039/study/Summator;.nStaticSum:(II)I // method@0025 0022e0: 0e00 |0014: return-void catches : (none) positions : 0x0008 line=29 0x000b line=30 0x000e line=31 0x0011 line=32 0x0014 line=33 locals : 0x0000 - 0x0015 reg=4 this Lcom/m039/study/Summator;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は本当にarmv5teディレクトリ内のすべてのファイルを解析（および記事にコピー）したくありません。したがって、これらのファイルからリンクと抜粋を提供しようとします。



上記のリストを見ると、ネイティブメソッドに違いはないことがわかります。どうして？実際にはそうであるはずですが、とにかく、リストにはネイティブメソッドがどのように抽出されるかのヒントはありません。



しかし、最初に、呼び出し自体（invoke-virtual）を考慮せず、すぐにそこにあるコードが小さくないと仮定してください。：したがって、私たちはそこに見つけたいものを事前に形成する

仮想静的のコントラスト-

-自己解凍機能

のアクションが抽出するために、次にどのような可能性が、どのくらいの、そして-



あなたが興味を持っているとの研究を損なうべきではないまで、残りを。

メソッド実行

リストを上から下に見ていきましょう。



sumメソッドを入力および取得するコードの一部：

 0022b8: 1303 2c00 |0000: const/16 v3, #int 44 // #2c 0022bc: 1302 2b00 |0002: const/16 v2, #int 43 // #2b 0022c8: 6e30 2e00 3402 |0008: invoke-virtual {v4, v3, v2}, Lcom/m039/study/Summator;.sum:(II)I // method@002e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一見、すべてが非常に簡単です。適切なレジスタが入力され、メソッドが取得されます。



この方法が内部からどのように見えるかを提案しようと思います。



const/16



-おそらく数値0で値44を仮想レジスタに入れ、次に値43を入れます（注：v1が仮想レジスタの指定であると仮定した場合、疑いはありません）



invoke-vritual



-この値をv4に入れて関数を呼び出します。

const / 16

  %verify "executed" /* const/16 vAA, #+BBBB */ FETCH_S(r0, 1) @ r0<- ssssBBBB (sign-extended) mov r3, rINST, lsr #8 @ r3<- AA FETCH_ADVANCE_INST(2) @ advance rPC, load rINST SET_VREG(r0, r3) @ vAA<- r0 GET_INST_OPCODE(ip) @ extract opcode from rINST GOTO_OPCODE(ip) @ jump to next instruction
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、2番目のバイトで送信された値を読み取り、その値を仮想レジスタに書き込みます。（再び）すべてが生成されたCコード（最適化されたバージョン）と同じように見えますが、2つの追加だけがあります：書き込み/読み取りごとに中間仮想レジスタが使用され、毎回新しいオペコードがロードされ、遷移が行われます。そうでなければ、すべてが非常に透明です。

呼び出す種類

2つの仮想レジスタがいっぱいです。ファイルOP_INVOKE_VIRTUAL.Sに移動してください。そして、深い恐怖があります。そのため、仮想（ファイルOP_INVOKE_VIRTUAL.S）と静的（OP_INVOKE_STATIC.S）の違いをすぐに理解しようとします。



コードによると、違いは2つの場所にあります。静的メソッドではなくdvmResolveMethod関数に渡される値には、追加の「.L $ {opcode} _continue：」が追加されます。



dvmResolveMethod関数の機能を検討してください。



この関数を呼び出す前に、レジスタは次のように埋められます。 （コメントからの抜粋）：

-r0 <-method-> clazz

-r1 <

-Priv * -r2 <-METHOD_VIRTUALまたはMETHOD_STATIC（method type）

-r3 <-glue-> method



*文書による命令形式 Priv、BBBBはコメントに記述され



ていますが、今度はdvmResolveMethod関数のコードに戻ります。関数の宣言を見ると、4番目の引数（上記を参照）が不要であることが明らかになります。

  Method* dvmResolveMethod(const ClassObject* referrer, u4 methodIdx, MethodType methodType)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数はMethod構造体へのポインターを返します。この関数について詳しく知る必要はありません。この構造を見てください。



興味深く有用な分野がたくさんありますが、特別な関心を提供する素晴らしい分野があります- nativeFunc



。したがって、この構造にはネイティブ関数へのポインタも含まれます。



ここで、この構造またはこのメソッドが「実行中」の場所を見つけておくといいでしょう。



OP_INVOKE_STATIC.SファイルとOP_INVOKE_VIRTUAL.Sの両方で、関数は最後に呼び出されbl common_invokeMethod${routine}



ます。ほとんどの場合、これはMethod構造のメインハンドラーであり、そのコードはfooter.Sファイルにあります。プレフィックス「NoRange」は、ファイルの最初の行のために表示されました- %default { ... , "routine" : "NoRange" }







しかし、footer.Sを見る前に、タイプの意味を確認できますDalvikBridgeFunc



フィールドでnativeMethod



？ VMコードを実行するとnativeMethod



、dvmResolveNativeMethod 関数がフィールドに割り当てられていることがわかります。



この関数のコメントから、ネイティブメソッド（ライブラリlibNAME.so内）を検索し、最も重要な実行に使用されることが明らかになります。それで彼女の言葉を聞いてみましょう。その場合はそれを信じるのが唯一の場合です。



もう1つ質問がありますが、ネイティブメソッドを実行するユーザーと場所が明確になりました。しかし、それでも、どこで完全に明確ではありません。結局、footer.Sファイルはレビューされませんでした。common_invokeMethodNoRange



関数に戻る。非常に恐ろしく、最後の部分で明確ではなかったもの、つまりrFPやrPCなどのレジスターを設定しているのは誰なのかという答えが含まれていることに注意してください。ご覧のとおり、この関数はそれらを埋めます。



ほんの少しの忍耐、そして、たとえば、rINST、rPC、r2が何で満たされているかを理解できますか？ method-> instフィールドへのポインター、つまり命令（バイトコード）。そして、そのような瞬間がたくさんあるので、それらを省略します。



しかし、ネイティブは興味があり、すべてがさらに簡単です。メソッドがネイティブの場合（対応するフラグがチェックされている場合）、既に処理したのと同じnativeFunc関数が実行されます。



それ以外の場合、common_invokeMethodNoRangeは以前に調べた標準オペコードと非常によく似ています。追加のチェックは多くあります。



しかし、静的または非静的メソッドはどうでしょうか？footer.Sは、どうやらそれらとは何の関係もありません。それらについて言えることはすべて、対応するオペコードファイル（invoke-virtualおよびinvoke-static）ですでに述べられています。



これについて、誰がどこで何を作成したかを明確にすることができます。そうでない場合、さらに理解することは難しくありません。私の仕事は、質問をすること（元の目標を参照）を示し、これを実際よりもよく理解することです。

パートIII。 まとめ

この部分では、ネイティブメソッドの取得を担当する関数が見つかりました。また、この関数が取得される場所と保存される場所も追跡しました。この知識があれば、Java言語の他の部分を見て、Dalvik VMコードでそれらを観察できます。



このパートの後、バイトコードは多くのオペコードであり、それぞれが相互に作用することが明らかになります。そして、この部分では、この相互作用のごく一部のみが考慮されました。



このトピックに興味がある場合は、将来的には逆アセンブルされた形式のJava言語の標準構造を検討し、プレゼンテーションで開発者のDalvik VMがAndroid用のJava言語でプログラミングするときに行うべきまたはすべきでない例を示した理由を理解できます。

まとめ

ここでは、この記事で見つけることができると思われるものから抜粋しようとします。



しかし、最初に、記事がどのようにコンパイルされるかについてのいくつかの機能を強調したいと思います。



テキストで「備考」という言葉に出くわしたかもしれません。これは、ドラフトで記事全体を書いた後に追加されました。そして、これらのコメントを追加する価値があるように思えました。



この記事の私の目標は、あいまいなコードを実際に研究するために必要な考え方を示すことです。私は非常に簡単な質問と、このために興味のあるオブジェクトを選択しました。したがって、多くの支部に会って、主題に対する態度がどのように変化するかに気付くことができます。



そして今、私にとって興味深いと思われること、そして研究の結果について少し説明します。 Java言語仕様には多くのことが書かれていますが、この記事の後では、これらの構造をそのまま理解する方がはるかに簡単です。



主なポイントは次のとおり



です。1.メソッド呼び出しは、静的、仮想（クイックプレフィックスを含む）が何であれ、メソッド呼び出しであり、単純なC（およびC ++）と比較した場合、それ自体非常に複雑です。たとえば、Box2Dのラッパーがあるとします。オブジェクトが交差するかどうかをチェックするために毎回（無限ループで）メソッドがこのラッパーから呼び出されると、対応する質問が発生します-なぜですか？これはCで行う必要がありますが、Javaでワールドを作成してオブジェクトを初期化できます。



2.オペコードの機能はアセンブラーの挿入に非常に近いため、オペコードはアセンブラーを使用して実装されます。当然、これらはJNIを介してサードパーティ関数を呼び出すよりも優れていますが、Cでそれを行うよりも悪いです



。2つの基準によって悪化します



。1）呼び出しに仮想レジスタを介してラッパーを使用します。モード。オペコードの速度はCの最適化されていないバージョンと非常に似ているとさえ言えます



。2）各オペコードには次のオペコードを取得するコードがありますが、それほど大きくはありません。抽出後、すでに簡単な指示のように見える次のものへの移行が行われbl



ます。



私は興味を失い、私が望んでいたことを知り、私の推測はほとんど正当化されました。あなたがそれを好きで、あなたが私と一緒にこのように行ったなら、私は非常に嬉しく思います。興味深い考えと、すべてがどのように機能するかに主な関心があることを願っています。



開発者はステレオタイプ（JavaとC / C ++に関して）を非常に頻繁に使用し、それらを破壊するためのわずかなアクションをどこにも表示しないことにしばしば気づきます。



あなたは追加の材料に興味がある場合は、ファイルのdocsフォルダに見ることができますJNI-tips.htmlとのプレゼンテーション 2008デベロッパーDavik VM。興味深いsmaliプロジェクトもありますが、私の手には届きませんでした。



PSすぐに謝罪します。間違えた場合は修正してください。すぐに変更を加えます。