C ++での例外処理に関する一連の記事の翻訳を続けています。



1部

3部

内部のC ++例外：かわいい性格

例外の作業を探索するという驚くべき旅への旅は終わりではありません。Unwindライブラリがスタックのアンラップを行うのに役立つ「呼び出しフレーム情報」と呼ばれるものをまだ調査する必要があります。メソッドが処理できるエラーを決定します。 また、ほとんどの魔法は、私たちがまだ実際に見たことのない個人的な機能で起こることも学びました。 転送エラーとキャッチエラーについて既に知っていること（または、より正確には、スローされたものがインターセプトされる方法を既に知っていること）を要約しましょう。

• コンパイラはthrow宣言をcxa_allocate_exception / xca_throwのペアに変換します
• __cxa_allocate_exceptionはメモリ内で例外をスローします
• __cxa_throwは展開操作を開始し、例外を低レベル展開ライブラリに渡し、 _Unwind_RaiseExceptionを発生させます
• スタック拡張では、CFIを使用して、現在スタックにある機能を見つけます。
• 各関数にはLSDAがあり、 .gcc_except_tableと呼ばれるものを追加します
• 展開は、現在のスタックフレームとLSDAを使用してパーソナル関数を呼び出します。現在の関数にこのタイプの例外ハンドラーがない場合、スタックは引き続き展開されます。

このすべてをすでに学んでいる限り、私たち自身の個人的な機能を書く時が来ました！ ABIは、例外がスローされたときに次を印刷するために使用されます。

alloc ex 1 __cxa_throw called no one handled __cxa_throw, terminate!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mycppabi



、次のようなものを追加しましょう。

 void __gxx_personality_v0() { printf("Personality function FTW\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私のgithubリポジトリで現在のコードを確認できます 。



そして、もちろん、アプリケーションを起動すると、個人の関数が呼び出されます。 私たちはそれを正しい道で見、そして私たちが彼女に何を望んでいるかを知っています。 正しい関数定義を使用しない理由：

 _Unwind_Reason_Code __gxx_personality_v0 ( int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これをmycppabi.cpp



、次のようになります。

 #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <stdint.h> namespace __cxxabiv1 { struct __class_type_info { virtual void foo() {} } ti; } #define EXCEPTION_BUFF_SIZE 255 char exception_buff[EXCEPTION_BUFF_SIZE]; extern "C" { void* __cxa_allocate_exception(size_t thrown_size) { printf(&"alloc ex %i\n", thrown_size); if (thrown_size > EXCEPTION_BUFF_SIZE) printf("Exception too big"); return &exception_buff; } void __cxa_free_exception(void *thrown_exception); #include <unwind.h> typedef void (*unexpected_handler)(void); typedef void (*terminate_handler)(void); struct __cxa_exception { std::type_info * exceptionType; void (*exceptionDestructor) (void *); unexpected_handler unexpectedHandler; terminate_handler terminateHandler; __cxa_exception * nextException; int handlerCount; int handlerSwitchValue; const char * actionRecord; const char * languageSpecificData; void * catchTemp; void * adjustedPtr; _Unwind_Exception unwindHeader; }; void __cxa_throw(void* thrown_exception, struct type_info *tinfo, void (*dest)(void*)) { printf("__cxa_throw called\n"); __cxa_exception *header = ((__cxa_exception *) thrown_exception - 1); _Unwind_RaiseException(&header->unwindHeader); // __cxa_throw     printf("no one handled __cxa_throw, terminate!\n"); exit(0); } void __cxa_begin_catch() { printf("begin FTW\n"); } void __cxa_end_catch() { printf("end FTW\n"); } _Unwind_Reason_Code __gxx_personality_v0 ( int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context) { printf("Personality function FTW!\n"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてをコンパイルしてリンクし、gdbの少しの助けを借りて、この関数の各パラメーターの分析を開始します。

 Breakpoint 1, __gxx_personality_v0 (version=1, actions=1, exceptionClass=134514792, unwind_exception=0x804a060, context=0xbffff0f0)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• バージョンとexceptionClassは、言語/ ABI /コンパイラ、ツールチェーン/ネイティブではなくネイティブの例外などに依存します。 ミニABIではこれについて心配する必要はありません。すべての例外をキャッチするだけです。
• アクション ： Unwindが個人的な機能に何をすべきかを伝えるために使用します（これについては後で説明します）
• unwind_exception ： __cxa_allocate_exceptionによってスローされた例外（...から継承されます。多くの算術演算がありますが、このポインターにより、元の例外にアクセスできます）
• context ：LSDAなど、現在のスタックフレームに関するすべての情報が含まれます。 コンテキストを使用して、現在のスタックで例外を処理できるものを決定します（デストラクタを呼び出すかどうかも決定します）。

さて、私たちは機能する（少なくともリンク可能な）個人的な機能を持っています。 それはあまり役に立たないので、実際の振る舞いで埋めて、例外を処理するようにします。

内部のC ++例外：2フェーズパス

Unwindが呼び出すことができるパーソナル関数を追加して、前の章を終了しました。 彼女は、一般的に、これまで何もしていません。 ABIはすでに例外をスローしてキャッチする作業の半分を実装していますが、個人的な機能はエラー処理のためにランディングパッドを正しく選択する方法を学習する必要があります。 この章は、 __ gxx_personality_v0関数が取るパラメーターを理解し、実際の動作を追加することから始めます。「はい、現在のスタックブロックは例外を処理できます」を出力します。



すでに、ミニABIのバージョンまたは例外クラスを吐き出したいと言っていました。 コンテキストについても忘れましょう。スタックの最初のフレームですべての例外を処理します。 メソッド呼び出しのすぐ上にある関数のtry / catchブロックを置き換えることを忘れないでください。例外をスローすると、すべてが壊れます。 また、catchブロックは例外のタイプを無視することを覚えておく価値があります。 例外を処理することを_Unwind_



関数に知らせるにはどうすればよいですか？



_Unwind_Reason_Code - Unwind関数に通知する個人関数による戻り値：エラーを処理するためのランディングパッドが見つかったかどうか。 パーソナル関数* _URC_HANDLER_FOUNDから戻り、何が起こるか見てみましょう。

 alloc ex 1 __cxa_throw called Personality function FTW Personality function FTW no one handled __cxa_throw, terminate!
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見える？ ハンドラーが見つかったことをアンラッパーに伝え、それが再びパーソナル関数を呼び出しました！ ここで何が起こっているのですか？



アクションパラメーターを覚えていますか？ 例外処理は検索とクリーンアップ（または_UA_SEARCH_PHASEと_UA_CLEANUP_PHASE）の2段階で行われるため、これがUnwindが彼が望むものを正確に伝える方法です。 エラー処理のレシピに戻りましょう。

• __cxa_throw / __ cxa_allocate_exceptionは例外を発生させ、それらを_Unwind_RaiseExceptionと呼ばれる低レベルのスタックプロモーションライブラリに渡します
  
  
  
  
• スピナーはCFIを使用して、現在スタックにある関数を見つけます（関数の展開を開始する方法を見つけます）
  
  
  
  
• 各関数には、.gcc_except_tableと呼ばれるものに追加されたLSDAパーツがあります
  
  
  
  
• スピナーは例外のランディングパッドを特定しようとします。
  
  
  
  
  • アンワインダーは、パラメーターaction： _UA_SEARCH_PHASEおよびパラメーターcontex：スタックの現在のフレームへのポインターを使用して、パーソナル関数を呼び出します。
  • パーソナル関数は、LSDAを分析することにより、現在のフレームスタックがこの例外を処理できるかどうかをチェックします。
  • 例外を処理できる場合、_URC_HANDLER_FOUNDを返します
  • 例外を処理する人がいない場合、_URC_CONTINE_UNWINDが返され、アンワインダーは次のスタックフレームでハンドラーを見つけようとし続けます。
  
  
  
• ランディングパッドが見つからない場合、デフォルトのハンドラーが呼び出されます（通常はstd :: terminate）。
  
  
  
  
• ランディングパッドが見つかった場合：
  
  
  • アンワインダーは、スタックを再度処理し始め、パラメーターaction _UA_CLEANUP_PHASEを使用してパーソナル関数を呼び出します。
  • パーソナル関数は、現在のスタックウィンドウがこの例外を処理できるかどうかをチェックします。
  • できない場合は、LSDAで説明されているクリーンアップ関数を起動し（デストラクタを呼び出して現在のスタックフレームに配置されているオブジェクトをクリアします）、次のフレームに進むようアンワインダに指示します。
  • 処理できる場合、クリーニングコードは実行されず、巻き取り機にランディングパッドでの実行を継続することを伝えるだけです。

次の2つの重要なことに注意してください。

1. 例外をキャッチする2フェーズモードで実行するということは、元のスタックトレース例外と完全なスタックトレース例外を取得できることを意味します（削除と一緒に1つのパスでデプロイした場合、スタックトレースがないか、そのコピーを保存する必要があります！）。
2. _UA_CLEANUP_PHASEを起動し、フレームが例外を処理できることがわかっている場合でも、各フレームを繰り返し呼び出すことも非常に重要です。パーソナル関数には、このスコープで作成されたオブジェクトのすべてのデストラクタを呼び出す機能があります。 これがRAII（Resource Acquisition Is Initialization）例外を安全なイディオムにするものです。

これで、ハンドラー検索フェーズがどのように機能するかを理解し、個人用関数を引き続き実装できます。

内部のC ++例外：最初の例外をキャッチする

前の章は、スピナーに反応する個人的な機能を教えることで終了しました。 __gxx_personality_v9の実際の動作を追加するときが来ました。2つのフェーズでパッセージを処理するように教えます。



私たちの個人的な機能は次の形式をとります

 _Unwind_Reason_Code __gxx_personality_v0 ( int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context) { if (actions &_UA_SEARCH_PHASE) { printf("Personality function, lookup phase\n"); return _URC_HANDLER_FOUND; } else if (actions & _UA_CLEANUP_PHASE) { printf("Personality function, cleanup\n"); return _URC_INSTALL_CONTEXT; } else { printf("Personality function, error\n"); return _URC_FATAL_PHASE1_ERROR; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

思い出させてください：ソースコードはgithubリポジトリにあります 。



実行して何が起こるか見てみましょう：

 alloc ex 1 __cxa_throw called Personality function, lookup phase Personality function, cleanup try_but_dont_catch handled the exception catchit handled the exception
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは機能しますが、何かがおかしいです：catch / tryブロック内のハンドラーは決して起動しません！ これは、パーソナル関数が「スクランブラー」に「コンテキストを設定する」（つまり、実行を継続する）ように指示するが、どのコンテキストを指示しないかという事実によるものです。 この場合、ランディングパッドブロックの後も実行を継続する可能性がありますが、これは未定義の動作です。 次に、 .gcc_except_table （旧友のLSDA）で利用可能な情報を使用して、コード（ランディングパッド）の実行を継続するポイントを指定する方法を確認します。

内部の C ++例外：現在のフレーム情報をアンワインド

ミニABIに例外をスローできるようにしておきましたが、現在は例外のキャッチに取り組んでいます。 例外を検出してリッスンできるパーソナル関数を実装しましたが、まだ終了していません。スピナーに停止すべきタイミングを通知できても、エラーハンドラーブロック内でコードを実行できません。 これは、私たちが始めた場所よりもすでに優れていますが、適切なABIエラー処理システムを作成する方法はまだまだあります。 コードを改善できますか？



catchブロック内でコードを実行し続けることができるように、スピナーにランディングパッドの場所をどのように伝えることができますか？ ABI仕様に戻ると、役立つコンテキスト管理機能がいくつかあります。

• _Unwind_GetLanguageSpecificDataを使用して、現在のフレームのLSDAを取得します。 この関数を使用してランディングパッドとデストラクタを検索する方法を学習する必要があります。
• _Unwind_GetRegionStartは、現在の関数の先頭にある命令へのポインター（現在のフレームに対応する関数へのポインター）を取得します
  
  
  
  
• スタックの現在のフレーム内の命令ポインター（命令ポインター）を取得する_Unwind_GetIP （次のフレームの関数呼び出しが完了する場所へのポインター。以下の例で明確になります）。

これらの機能をgdbで見てみましょう。 私の車で：

 Breakpoint 1, __gxx_personality_v0 (version=1, actions=6, exceptionClass=134515400, unwind_exception=0x804a060, context=0xbffff0f0) at mycppabi.cpp:77 84 const uint8_t* lsda = (const uint8_t*)_Unwind_GetLanguageSpecificData(context); 85 uintptr_t ip = _Unwind_GetIP(context) - 1; 86 uintptr_t funcStart = _Unwind_GetRegionStart(context); 87 uintptr_t ipOffset = ip - funcStart;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの変数を調べると、 _Unwind_GetRegionStartが現在のスタックフレーム（try_but_dont_catch）を指し、 _Unwind_GetIpが次のフレームが呼び出された位置のIPであることがわかります。 _Unwind_GetRegionStartは、例外が最初にスローされた場所を示します。説明するのは少し難しいので、後でそれを残しましょう。 ここにはまだLSDAポインターが表示されていませんが、_Unwind_GetLanguageSpecificDataが関数の終了後の行を直接参照している限り、関数コードのすぐ後ろにあると想定できます。

 _Unwind_GetIP = (void *) 0x804861d _Unwind_GetRegionStart = (void *) 0x8048612 _Unwind_GetLanguageSpecificData = (void *) 0x8048e3c function pointer to try_but_dont_catch = 0x8048612 &<try_but_dont_catch()> (gdb) disassemble /m try_but_dont_catch Dump of assembler code for function try_but_dont_catch(): 10 void try_but_dont_catch() { [...] 11 try { 12 raise(); 0x08048619 <+7>: call 0x80485e8 <raise()> 13 } catch(Fake_Exception&) { 0x08048651 <+63>: call 0x804874a <__cxa_begin_catch()> 0x08048665 <+83>: call 0x804875e <__cxa_end_catch()> 0x0804866a <+88>: jmp 0x804861e <try_but_dont_catch()+12> 14 printf("Caught a Fake_Exception!\n"); 0x08048659 <+71>: movl $0x8048971,(%esp) 0x08048660 <+78>: call 0x80484c0 <puts@plt> 15 } 16 17 printf("try_but_dont_catch handled the exception\n"); 0x0804861e <+12>;: movl $0x8048948,(%esp) 0x08048625 <+19>: call 0x80484c0 <puts@plt> 18 } 0x0804862a <+24>: add $0x24,%esp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Unwindを使用すると、現在のスタックフレームに関する十分な情報を取得して、例外を処理できるかどうかと、その処理方法を判断できます。 ランディングパッドを決定できるかどうかを判断する前に必要な最後の手順は、関数の最後にCFI情報を解釈することです。 これはDWARF仕様の一部であり、その実装はやや複雑です。 ABIと同様に、必要な最小値を使用します。

内部のC ++例外：CFIテーブルの読み取り

例外を正しく処理するには、ABIに実装する個人機能がLSDAを読み取って、どのフレーム（つまり、どの機能）が例外とどの例外を処理できるか、およびランディングパッド（キャッチ-ブロック）が見つかりました。 LSDAテーブルはCFI形式で定義されており、この章ではその読み方を学びます。



CFIデータは非常に簡単に読み取ることができますが、考慮すべき落とし穴がいくつかあります。 実際、2つ：

1. .gcc_except_tableに関するドキュメントはほとんどありません（実際、数文字しか見つかりませんでした）。したがって、多くのソースコードを調べ、逆アセンブルされたコードを理解する必要があります。
2. 形式自体は地獄のように複雑ではないという事実にもかかわらず、LEB（リトルエンディアンベース）を使用しているため、このテーブルの読み取りは特に簡単ではありません。

私の知る限り、ほとんどのDWARFデータはLEBでエンコードされます。これは、プログラマを混乱させ、任意の長さのintをエンコードするためのコードのスペースを削減する素晴らしいアイデアです。 幸いなことに、ここで少しカウントできます。基本的に、LEBでエンコードされた数値は、単純なuint8_tで読み取られます。これは、大きな例外テーブルなどを処理しないためです。



いつものように、この章の現在のバージョンのコードはリポジトリにあります 。



分解から直接CFIの分析を開始し、個人的な機能でこのデータを読み取るために何かを構築できるかどうかを確認しましょう。 タグの名前をより人間に優しいものに変更しました。 LSDAには3つのセクションがあります。以下に定義してみてください。

 .local_frame_entry: .globl __gxx_personality_v0 .section .gcc_except_table,"a",@progbits .align 4
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが非常に単純です。グローバルとして__gxx_personality_v0を使用するという見出しだけで、リンカーに.gcc_except_tableセクションを定義することを知らせます。



次に進みます：

 .local_lsda_1: #   .     .byte 0xff #    landing pads;  0, func's ptr #   (_Unwind_GetRegionStart) .byte 0 #   LSDA:   LLSDATT1  LLSDATTD1  #    LSDA,  .uleb128 .local_lsda_end - .local_lsda_call_site_table_header
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すでに多くの情報があります。 これらのラベルは非常にあいまいですが、パターンに従います。 LSDAは言語固有のデータゾーンを意味し、先頭のLは「ローカル」を意味するため、これらはローカルです（翻訳されたモジュール、.oファイルの場合）。 ゾーンナンバーワンデータ。 他のマークも同じパターンに従いますが、それらの説明は引き受けませんでした。 そして、一般的に、それらは私たちにとって必要ではありません。

 .local_lsda_call_site_table_header: # Encoding of items in the landing pad table. Again, we don't care. .byte 0x1. # The length of the call site table (ie the landing pads) .uleb128 .local_lsda_call_site_table_end - .local_lsda_call_site_table
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別の退屈な見出し、さらに進んでみましょう：

 .local_lsda_call_site_table: .uleb128 .LEHB0-.LFB1 .uleb128 .LEHE0-.LEHB0 .uleb128 .L8-.LFB1 .uleb128 0x1 .uleb128 .LEHB1-.LFB1 .uleb128 .LEHE1-.LEHB1 .uleb128 0 .uleb128 0 .uleb128 .LEHB2-.LFB1 .uleb128 .LEHE2-.LEHB2 .uleb128 .L9-.LFB1 .uleb128 0 .local_lsda_call_site_table_end:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは非常に興味深いものです。ここでは、自分の目で呼び出しテーブルを確認します。 どういうわけか、これらのすべてのエントリで、着陸台を見つける必要があります。 インターネット上のランダムなページに従って、各エントリの形式は構造に対応する必要があります。

 struct lsda_call_site_entry { //  IP  size_t cs_start; //  IP  size_t cs_len; // Landing pad  size_t cs_lp; //     size_t cs_action; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まあ、私たちは正しい道を進んでいるように見えますが、ランギングパッドを1つだけ特定したとき、なぜ3つのエントリポイントがあるのか​​まだわかりません。 いずれにせよ、少しカウントできます。逆アセンブルされたコードを見ると、すべてのCFI値が128未満であると判断できます。つまり、LEBエンコーディングはucharとして読み取ることができます。 これにより、CFIの読み取りコードがはるかに簡単になり、個人機能でさらに使用する方法がわかりました。

内部のC ++例外：突然、C ++のリフレクション

すでに行ったことを思い出してください：エラーをスローする方法を学び、エラーを検出して処理できるパーソナル関数__gxx_personality_v0を作成し、スタッカーに停止するタイミングを伝えますが、それでも必要なキャッチブロックの決定方法がわかりません。 また、LSDAを読むことを学びましたが、今ではこれらすべてを組み合わせることができます！



このようなことをして、正しい軌道に乗っているかどうかを確認しましょう（このコードはuint8でしか動作せず、おそらく移植性がないことに注意してください）。

 struct LSDA_Header { uint8_t lsda_start_encoding; uint8_t lsda_type_encoding; uint8_t lsda_call_site_table_length; }; struct LSDA_Call_Site_Header { uint8_t encoding; uint8_t length; }; struct LSDA_Call_Site { LSDA_Call_Site(const uint8_t *ptr) { cs_start = ptr[0]; cs_len = ptr[1]; cs_lp = ptr[2]; cs_action = ptr[3]; } uint8_t cs_start; uint8_t cs_len; uint8_t cs_lp; uint8_t cs_action; }; _Unwind_Reason_Code __gxx_personality_v0 ( int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context) { if (actions & _UA_SEARCH_PHASE) { printf("Personality function, lookup phase\n"); return _URC_HANDLER_FOUND; } else if (actions & _UA_CLEANUP_PHASE) { printf("Personality function, cleanup\n"); const uint8_t* lsda = (const uint8_t*) _Unwind_GetLanguageSpecificData(context); LSDA_Header *header = (LSDA_Header*)(lsda); LSDA_Call_Site_Header *cs_header = (LSDA_Call_Site_Header*) (lsda + sizeof(LSDA_Header)); size_t cs_in_table = cs_header->length / sizeof(LSDA_Call_Site); //    cs_table_base  uint8,    //    const uint8_t *cs_table_base = lsda + sizeof(LSDA_Header) + sizeof(LSDA_Call_Site_Header); //    call site  for (size_t i=0; i < cs_in_table; ++i) { const uint8_t *offset = &cs_table_base[i * sizeof(LSDA_Call_Site)]; LSDA_Call_Site cs(offset); printf("Found a CS:\n"); printf("\tcs_start: %i\n", cs.cs_start); printf("\tcs_len: %i\n", cs.cs_len); printf("\tcs_lp: %i\n", cs.cs_lp); printf("\tcs_action: %i\n", cs.cs_action); } uintptr_t ip = _Unwind_GetIP(context); uintptr_t funcStart = _Unwind_GetRegionStart(context); uintptr_t ipOffset = ip - funcStart; return _URC_INSTALL_CONTEXT; } else { printf("Personality function, error\n"); return _URC_FATAL_PHASE1_ERROR; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際のコード



ご覧のとおり（このコードを実行した場合）、呼び出しテーブルのすべてのポイントは相対的です。 何の親Relative？ もちろん、機能を開始します。 つまり、特定のランディングパッドのEIP（命令ポインター）を取得する場合、必要な作業は_Unwind_GetRegionStart + LSDA_Call_Site.cs_Ip！を追加するだけです。



最後に、問題を解決できるようになりました。正しいランディングパッドを実行するように個人機能を変更しましょう。 次に、別のUnwind関数を使用して、実行を継続する場所を示す必要があります： _Unwind_SetIP 。 最初の着陸台を起動するために、個人機能を再度変更します。

 const uint8_t *cs_table_base = lsda + sizeof(LSDA_Header) + sizeof(LSDA_Call_Site_Header); for (size_t i=0; i < cs_in_table; ++i) { const uint8_t *offset = &cs_table_base[i * sizeof(LSDA_Call_Site)]; LSDA_Call_Site cs(offset); if (cs.cs_lp) { uintptr_t func_start = _Unwind_GetRegionStart(context); _Unwind_SetIP(context, func_start + cs.cs_lp); break; } } return _URC_INSTALL_CONTEXT;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードを実行してみて、美しい永久ループを観察してください。 何が間違っていたと思いますか？ 答えは次の章にあります！

内部のC ++例外：ランディングパッドのコンテキストの設定

最後の章で、私たちはついにほとんど機能する個人的な機能を書きました。 使用可能なランディングパッドで各スタックフレームを定義し、実行したい内容をUnwindに正確に伝えることができます。 ただし、小さな問題が発生しました。Unwindコンテキストを設定して正しいランディングパッドで実行を継続するには、現在の例外をレジスタに設定する必要があります。 これは基本的に、ランディングパッドはどの例外を処理する必要があるかを知りたくないため、「これを処理できません」とのみ表示します。 アンワインドは「次のランディングパッドを試してください」と言いますが、ABIは非常に単純なので、別のランディングパッドを見つける方法さえ考えられず、同じものを滑らせようとします。何回も。しばらくの間、最も不自然な例が出てきたようです（true）！



ランディングパッドのコンテキストを修正し、ABIを少し改善しましょう。

 #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <stdint.h> namespace __cxxabiv1 { struct __class_type_info { virtual void foo() {} } ti; } #define EXCEPTION_BUFF_SIZE 255 char exception_buff[EXCEPTION_BUFF_SIZE]; extern "C" { void* __cxa_allocate_exception(size_t thrown_size) { printf("alloc ex %i\n", thrown_size); if (thrown_size > EXCEPTION_BUFF_SIZE) printf("Exception too big"); return &exception_buff; } void __cxa_free_exception(void *thrown_exception); #include <unwind.h> typedef void (*unexpected_handler)(void); typedef void (*terminate_handler)(void); struct __cxa_exception { std::type_info * exceptionType; void (*exceptionDestructor) (void *); unexpected_handler unexpectedHandler; terminate_handler terminateHandler; __cxa_exception * nextException; int handlerCount; int handlerSwitchValue; const char * actionRecord; const char * languageSpecificData; void * catchTemp; void * adjustedPtr; _Unwind_Exception unwindHeader; }; void __cxa_throw(void* thrown_exception, struct type_info *tinfo, void (*dest)(void*)) { printf("__cxa_throw called\n"); __cxa_exception *header = ((__cxa_exception *) thrown_exception - 1); _Unwind_RaiseException(&header->unwindHeader); // __cxa_throw never returns printf("no one handled __cxa_throw, terminate!\n"); exit(0); } void __cxa_begin_catch() { printf("begin FTW\n"); } void __cxa_end_catch() { printf("end FTW\n"); } /**********************************************/ /** * The LSDA is a read only place in memory; we'll create a typedef for * this to avoid a const mess later on; LSDA_ptr refers to readonly and * &LSDA_ptr will be a non-const pointer to a const place in memory */ typedef const uint8_t* LSDA_ptr; struct LSDA_Header { /** * Read the LSDA table into a struct; advances the lsda pointer * as many bytes as read */ LSDA_Header(LSDA_ptr *lsda) { LSDA_ptr read_ptr = *lsda; // Copy the LSDA fields start_encoding = read_ptr[0]; type_encoding = read_ptr[1]; ttype = read_ptr[2]; // Advance the lsda pointer *lsda = read_ptr + sizeof(LSDA_Header); } uint8_t start_encoding; uint8_t type_encoding; uint8_t ttype; }; struct LSDA_CS_Header { // Same as other LSDA constructors LSDA_CS_Header(LSDA_ptr *lsda) { LSDA_ptr read_ptr = *lsda; encoding = read_ptr[0]; length = read_ptr[1]; *lsda = read_ptr + sizeof(LSDA_CS_Header); } uint8_t encoding; uint8_t length; }; struct LSDA_CS { // Same as other LSDA constructors LSDA_CS(LSDA_ptr *lsda) { LSDA_ptr read_ptr = *lsda; start = read_ptr[0]; len = read_ptr[1]; lp = read_ptr[2]; action = read_ptr[3]; *lsda = read_ptr + sizeof(LSDA_CS); } // Note start, len and lp would be void*'s, but they are actually relative // addresses: start and lp are relative to the start of the function, len // is relative to start // Offset into function from which we could handle a throw uint8_t start; // Length of the block that might throw uint8_t len; // Landing pad uint8_t lp; // Offset into action table + 1 (0 means no action) // Used to run destructors uint8_t action; }; /**********************************************/ _Unwind_Reason_Code __gxx_personality_v0 ( int version, _Unwind_Action actions, uint64_t exceptionClass, _Unwind_Exception* unwind_exception, _Unwind_Context* context) { if (actions & _UA_SEARCH_PHASE) { printf("Personality function, lookup phase\n"); return _URC_HANDLER_FOUND; } else if (actions & _UA_CLEANUP_PHASE) { printf("Personality function, cleanup\n"); // Pointer to the beginning of the raw LSDA LSDA_ptr lsda = (uint8_t*)_Unwind_GetLanguageSpecificData(context); // Read LSDA headerfor the LSDA LSDA_Header header(&lsda); // Read the LSDA CS header LSDA_CS_Header cs_header(&lsda); // Calculate where the end of the LSDA CS table is const LSDA_ptr lsda_cs_table_end = lsda + cs_header.length; // Loop through each entry in the CS table while (lsda < lsda_cs_table_end) { LSDA_CS cs(&lsda); if (cs.lp) { int r0 = __builtin_eh_return_data_regno(0); int r1 = __builtin_eh_return_data_regno(1); _Unwind_SetGR(context, r0, (uintptr_t)(unwind_exception)); // Note the following code hardcodes the exception type; // we'll fix that later on _Unwind_SetGR(context, r1, (uintptr_t)(1)); uintptr_t func_start = _Unwind_GetRegionStart(context); _Unwind_SetIP(context, func_start + cs.lp); break; } } return _URC_INSTALL_CONTEXT; } else { printf("Personality function, error\n"); return _URC_FATAL_PHASE1_ERROR; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードの現在のバージョンとLSDAのより詳細な説明。



最後に動作します！次のようなものを取得する必要があります。

 ./app alloc ex 1 __cxa_throw called Personality function, lookup phase Personality function, cleanup begin FTW Caught a Fake_Exception! end FTW try_but_dont_catch handled the exception catchit handled the exception
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、Unwindを少しtrickしました。最初のcatchブロックで、すべての例外を連続して処理するように彼に伝えました。これにより、catch（Exception＆）がcatch（...）に変わり、フレーム内の最初の関数にcatchブロックがない場合、すべての地獄が破壊されます。ただし、非常に単純なABIを作成するための最初のステップを実行しました！



コードを改善し、正しいフレームで例外を正しく処理することができますか？もちろん！



ボンネットの下のC ++例外：いくつかのランディングパッドとグルの教え



困難な方法の後、ついにlbstdc ++の助けを借りずにエラーを処理できる実用的な個人用関数を作成しました。すべてのエラーをランダムに処理しますが、機能します！正しい例外処理はまだ答えられていない大きな質問ですが、LSDAに戻ると、次のようなことがわかります。

 .local_lsda_call_site_table: .uleb128 .LEHB0-.LFB1 .uleb128 .LEHE0-.LEHB0 .uleb128 .L8-.LFB1 .uleb128 0x1 .uleb128 .LEHB1-.LFB1 .uleb128 .LEHE1-.LEHB1 .uleb128 0 .uleb128 0 .uleb128 .LEHB2-.LFB1 .uleb128 .LEHE2-.LEHB2 .uleb128 .L9-.LFB1 .uleb128 0 .local_lsda_call_site_table_end:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つのtry / catchブロックを記述した場合でも、3つのランディングパッドがあります。 ここで何が起こっていますか？



前の章を注意深く見ると、LSDA_CS構造体の定義にいくつかのコメントが追加されていることがわかります。

 struct LSDA_CS { // len  lp   void*'s,   // : start and lp   , len //   //   ,     uint8_t start; //   uint8_t len; // Landing pad uint8_t lp; //  action table + 1 (0  " ") //     uint8_t action; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここには多くの興味深いものがありますが、最初にこの例のフィールドごとに構造を見てください。

 void foo() { L0: try { do_something(); L1: } catch (const Exception1& ex) { ... } catch (const Exception2& ex) { ... } catch (const ExceptionN& ex) { ... } catch (...) { } L2: }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• Ip：着陸パッドが始まる機能の開始からのオフセット。この例の値はL1-addr_of（foo）である必要があります
• action: . . , .
• start: try- . L0 — addr_of(foo)
• len: try-. L1-L0

関心のあるフィールドはstartとlenです：try / catchブロックが多い関数では、現在のフレームの命令ポインター（IP）がstartとstart + lenの間にあるかどうかを確認することで、例外を処理する必要があるかどうかを判断できます。



これにより、複数のtry / catchブロックを持つ関数が複数の例外を処理できるという神話が破壊されますが、1つのランディングパッドに対して3つのオブジェクトが生成されるのはなぜですか？他のオブジェクトは、転送可能なクリーニングアクションまたはランディングパッドの場所として配置されます。



継続