IL2CPP：生成されたコードをデバッグするためのヒント

IL2CPPシリーズの3番目の記事では、生成されたC ++コードのデバッグに関する有用なヒントについて説明します。ブレークポイントの設定方法、文字列とユーザータイプの内容の表示方法、例外の発生場所の特定方法です。

.NET ILコードだけから生成されたC ++コードのデバッグは楽しい作業ではないことに注意してください。 それでも、以下のヒントは、Unityプロジェクトコードがターゲットデバイスでどのように実行されるかを理解するのに役立ちます（記事の最後で、マネージコードのデバッグについても少しお話します）。

プロジェクトで生成されたコードがここに表示されているものと異なる可能性があることに注意してください。 Unityの各新バージョンでは、生成されたコードを最適化し、さらにコンパクトで生産性の高いものにするよう努めています。









仕事の準備



この記事では、OSXでUnityバージョン5.0.1p3を使用します。 例として、 前の記事のプロジェクトを取り上げますが、今回は、IL2CPPスクリプトエンジンを使用して、ターゲットiOSプラットフォーム用にプロジェクトを組み立てます。 前の記事のように、il2cpp.exeがILコードの名前に基づいてC ++コードのタイプとメソッドの名前を生成するように、Development Playerオプションをオンにしました。



Unityがプロジェクトを生成したら、Xcodeでそれを開き（バージョン6.3.1をインストールしましたが、別の現在のバージョンでもインストールできます）、ターゲットデバイス（iPad Mini 3または任意のiOSデバイス）を選択してビルドできます。



ブレークポイント



プロジェクトを開始する前に、HelloWorldクラスのStartメソッドの先頭にブレークポイントを配置します。 前の記事でわかるように、このメソッドは、生成されたC ++コードではHelloWorld_Start_m3と呼ばれます。 Cmd + Shift + Oを押すと、Xcodeでメソッドを見つけるためにメソッドの名前を入力し始め、そこにブレークポイントを設定します。







[デバッグ]> [ブレークポイント]> [シンボルブレークポイントの作成]（[デバッグ]> [ブレークポイント]> [キャラクターブレークポイントの作成]）を選択することでも同じことができます。







さて、Xcodeプロジェクトを開始すると、メソッドの最初の部分で中断されます。

同様に、名前がわかっている場合は、生成されたコードの他のメソッドにブレークポイントを設定できます。 さらに、Xcodeでは、ファイルの行にブレークポイントを直接設定できます。 生成されたファイルはすべてXcodeプロジェクトにあります。これを行うには、プロジェクトナビゲーターのClasses / Nativeディレクトリに移動します。







行ビュー

XcodeでIL2CPP文字列表現を表示するには2つの方法があります：直接またはlibil2cppのユーティリティを使用して、Xcodeで表示するために文字列をstd :: stringオブジェクトに変換します。 _stringLiteral1という文字列の値を見てみましょう。

Ctagsビルトインユーティリティ（またはXcodeのCmd + Ctrl + Jコマンド）を使用して、タイプIl2CppString_14の_stringLiteral1の定義に進むことができます。

struct Il2CppString_14 { Il2CppDataSegmentString header; int32_t length; uint16_t chars[15]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IL2CPPのほぼすべての行にこの表現があります。 Il2CppStringの定義は、ヘッダーファイルobject-internals.hにあります。 最初に、IL2CPPの管理対象タイプの標準ヘッダー-Il2CppObject（typedef宣言Il2CppDataSegmentStringによってアクセス）、次に4バイトの文字列長とUTF-16形式の2バイト文字の配列があります。 コンパイル中に定義された_stringLiteral1などの行は、固定長の文字の配列を取得し、実行時に生成された行は選択された配列を取得します。



_stringLiteral1を[ウォッチ]ウィンドウに追加し、[_ stringLiteral1のメモリの表示]オプションを選択して、メモリ内の行の表示を確認します。







Memory Viewerに表示されるものは次のとおりです。







行ヘッダーには16バイトが必要です。 0x000E（14）の値を持つ行サイズの場合、4バイトが続きます。 それらの次のバイトは、文字列の最初の文字、0x0048（H）です。 理論的には、1文字は2バイトを占有しますが、この行の各文字はバイト単位で配置されるため、右側のビューではドットで区切られています。 ただし、すべてが非常に読みやすいです。 この方法は確かに機能しますが、長い文字列にはあまり適していません。



Xcodeのlldbデバッガーを使用して、文字列の内容を表示することもできます。 utils / StringUtils.hヘッダーは、libil2cppの有用なユーティリティのインターフェイスを提供します。 たとえば、lldbコマンドラインからUtf16ToUtf8メソッドを呼び出しましょう。 インターフェイスは次のようになります。

 static std::string Utf16ToUtf8 (const uint16_t* utf16String);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

C ++構造体のchars要素をこのメソッドに渡すと、UTF-8形式のstd :: stringオブジェクトとして返されます。 この場合、lldbプロンプトでpコマンドを使用して、文字列の内容を印刷できます。

 (lldb) p il2cpp::utils::StringUtils::Utf16ToUtf8(_stringLiteral1.chars) (std::__1::string) $1 = "Hello, IL2CPP!"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カスタムタイプを表示する

さらに、カスタムタイプのコンテンツを表示できます。 このプロジェクト用に作成した簡単なスクリプトには、Importantという名前のC＃型とInstanceIdentifierフィールドがあります。 このタイプの2番目のインスタンスを作成した直後にブレークポイントを設定すると、生成されたコードのInstanceIdentifierフィールドの値が自然に1になることがわかります。







したがって、生成されたコードのユーザー定義型の内容は、XcodeのC ++コードとまったく同じ方法で表示できます。



例外発生時のコード実行の中断

生成されたコードをデバッグしてエラーの原因を突き止める必要がよくあり、ほとんどの場合、ガイド付き例外が関係しています。 先ほど言ったように、IL ++はC ++例外を使用して、マネージ例外を実装します。 Xcodeでこの状況でコードの実行を中断する方法はいくつかあります。



最も簡単なのは、管理対象例外がスローされるたびにil2cpp.exeが使用するil2cpp_codegen_raise_exception関数にブレークポイントを設定することです。







その後、プロジェクトの実行を許可すると、XcodeはStartメソッドコードがInvalidOperationExceptionをスローしたときにプロジェクトを停止します。 この場合、文字列の内容を表示すると非常に便利です。 たとえば、ex引数では、例外メッセージのある行を指す___message_2要素に注目できます。







上記の手順を使用すると、この行の内容を印刷して問題の原因を見つけることができます。

 (lldb) p il2cpp::utils::StringUtils::Utf16ToUtf8(&ex->___message_2->___start_char_1) (std::__1::string) $88 = "Don't panic"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この行は上に示したものと非常に似ていますが、生成されたフィールドの名前はわずかに異なることに注意してください。 charsフィールドは___start_char_1と呼ばれ、uint16_t []ではなく、uint16_t型です。 ただし、これは依然として配列の最初の文字であり、そのアドレスを変換関数に渡すことができます。



ただし、生成されたコードはすべてのマネージ例外をスローしません。 libil2cppランタイムコードは、一部の場合にのみこれを行いますが、それでもil2cpp_codegen_raise_exception関数を呼び出すことはありません。 それらを傍受する方法は？



例外ブレークポイント（[デバッグ]> [ブレークポイント]> [例外ブレークポイントの作成]）を作成すると、パラメーターでC ++例外を選択できるため、タイプIl2CppExceptionWrapperの例外がスローされたときにコード実行が中断されます。 したがって、すべてのマネージ例外はC ++型でラップされているため、キャッチできます。







これがどのように機能するかをテストするには、Startメソッドの先頭に次の2行を追加します。

 Important boom = null; Debug.Log(boom.InstanceIdentifier);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2行目はNullReferenceExceptionをスローします。 Xcodeでこのコードを実行すると（以前に例外のブレークポイントが設定されているため）、例外がスローされたときに実行が実際に中断されることがわかります。 ただし、ブレークポイントはlibil2cppコード内にあるため、アセンブラコードのみが表示されます。 呼び出しスタックでは、il2cpp.exeによって実装されるNullCheckメソッドにいくつかのフレームを移動する必要があります。







この時点で、1つのフレームに戻って、Important型のインスタンスが実際にNULLであることがわかります。







おわりに

これらのヒントが、IL2CPPによって生成されたC ++コードで発生する問題を追跡する方法を理解するのに役立てば幸いです。 このようなデバッグをよりよく理解するために、IL2CPPで使用される他のタイプを詳しく調べることをお勧めします。



マネージコードデバッガーについてはどうでしょうか。 デバイスでIL2CPPマネージコードをデバッグできることは本当に素晴らしいことです。

そして、IL2CPP用の組み込みデバッガーのアルファ版が既にあります。 引き続き作業を行っていますので、ご期待ください。



このシリーズの次回の記事では、IL2CPPでメソッド呼び出しを実装するいくつかの方法を検討し、パフォーマンスの観点からそれらを比較します。