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



1部

2部

ボンネットの下のC ++例外：適切なランディングパッドを見つける

これは私たちの長い歴史の中で15番目の章です。 例外がどのように機能するかについてはすでに多くのことを学びました。また、キャッチブロックの場所を決定する少量のリフレクション（例外に関するランディングパッド）を備えた独自の機能を記述しました。 前の章では、例外を処理できる個人用関数を作成しましたが、常に最初のランディングパッド（つまり、最初のcatchブロック）のみを置き換えます。 いくつかのキャッチブロックがある関数で適切なランディングパッドを選択する機能を追加して、個人の機能を改善しましょう。



TDD（テスト駆動開発）modに続いて、最初にABIのテストを作成できます。 プログラムthrow.cppを改善し、いくつかのtry / catchブロックを作成します。

#include <stdio.h> #include "throw.h" struct Fake_Exception {}; void raise() { throw Exception(); } void try_but_dont_catch() { try { printf("Running a try which will never throw.\n"); } catch(Fake_Exception&) { printf("Exception caught... with the wrong catch!\n"); } try { raise(); } catch(Fake_Exception&) { printf("Caught a Fake_Exception!\n"); } printf("try_but_dont_catch handled the exception\n"); } void catchit() { try { try_but_dont_catch(); } catch(Fake_Exception&) { printf("Caught a Fake_Exception!\n"); } catch(Exception&) { printf("Caught an Exception!\n"); } printf("catchit handled the exception\n"); } extern "C" { void seppuku() { catchit(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストする前に、このテストの立ち上げ中に何が起こるか考えてみてください。 try_but_dont_catch関数に注目してください。最初のtry / catchブロックは例外をスローせず、2番目のブロックはキャッチせずにスローします。 ABIが少し鈍い限り、最初のcatchブロックは2番目のブロックの例外を処理します。 しかし、最初のキャッチが処理された後はどうなりますか？ 実行は、最初のcatch / tryが終了した場所から続行され、再び例外をスローする2番目のtry / catchブロックの直前になります。これにより、最初のハンドラーは再び処理します。 無限ループ！ さて、再び（本当の）非常に複雑になりました！



LSDAテーブルの開始/長さフィールドの知識を使用して、着陸パッドを正しく選択します。 これを行うには、例外がスローされたときにIPが何であったかを知る必要があり、すでに知っているUnwind関数_Unwind_GetIPでそれを把握できます。 _Unwind_GetIPが返す内容を理解するために、例を見てみましょう。

 void f1() {} void f2() { throw 1; } void f3() {} void foo() { L1: try{ f1(); } catch(...) {} L2: try{ f2(); } catch(...) {} L3: try{ f3(); } catch(...) {} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、f2のcatchブロックでパーソナル関数が呼び出され、スタックは次のようになります。

 +------------------------------+ | IP: f2 stack frame: f2 | +------------------------------+ | IP: L3 stack frame: foo | +------------------------------+
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IPはL3に設定されますが、L2で例外がスローされることに注意してください。 これは、IPが実行されるべき次の命令を示すためです。 これは、例外がスローされたIPを取得する場合は1を減算する必要があることを意味します。そうしないと、_Unwind_GetIPの結果がランディングパッドの外側になる可能性があります。 パーソナル機能に戻ります：

 _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"); //  --    IP //   ,     uintptr_t throw_ip = _Unwind_GetIP(context) - 1; //    LSDA LSDA_ptr lsda = (uint8_t*)_Unwind_GetLanguageSpecificData(context); //   LSDA LSDA_Header header(&lsda); //  LSDA CS LSDA_CS_Header cs_header(&lsda); //    LSDA CS const LSDA_ptr lsda_cs_table_end = lsda + cs_header.length; //      CS while (lsda < lsda_cs_table_end) { LSDA_CS cs(&lsda); //    LP,      ,   if (not cs.lp) continue; uintptr_t func_start = _Unwind_GetRegionStart(context); //    IP   lp //  LP    ,  // IP         uintptr_t try_start = func_start + cs.start; uintptr_t try_end = func_start + cs.start + cs.len; // :    LP   try  if (throw_ip < try_start) continue; if (throw_ip > try_end) continue; //    landing pad   ;   int r0 = __builtin_eh_return_data_regno(0); int r1 = __builtin_eh_return_data_regno(1); _Unwind_SetGR(context, r0, (uintptr_t)(unwind_exception)); // ,        ; //     _Unwind_SetGR(context, r1, (uintptr_t)(1)); _Unwind_SetIP(context, func_start + cs.lp); break; } return _URC_INSTALL_CONTEXT; } else { printf("Personality function, error\n"); return _URC_FATAL_PHASE1_ERROR; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いつものように、現在のサンプルコードはこちらです。



もう一度実行して、出来上がり！ 無限ループはもうありません！ 簡単な変更により、適切なランディングパッドを選択できました。 次に、最初の代わりに正しいスタックフレームを選択するように個人機能を教えます。

ボンネットの下のC ++例外：ランディングパッドで適切なキャッチブロックを見つける

複数のランディングパッドを備えた機能を処理できる個人用機能を既に作成しました。 ここで、どの特定のブロックが特定の例外を処理できるか、言い換えると、どのブロックがキャッチして私たちを呼び出すかを認識しようとします。



もちろん、どのブロックが例外を処理できるかを判断するのは簡単なことではありません。 しかし、あなたは本当に何か他のものを期待していましたか？ 現在の主な問題は次のとおりです。

• 最初とメイン：このcatch-blockで受け入れられたタイプの例外をどこでどのように見つけることができます。
• キャッチタイプを見つけることができたとしても、どのようにキャッチを処理できますか（...）？
• 複数のキャッチブロックがあるランディングパッドの場合、可能なすべてのキャッチタイプをどのように見つけることができますか？
• 例を見てみましょう：

  struct Base {}; struct Child : public Base {}; void foo() { throw Child; } void bar() { try { foo(); } catch(const Base&){ ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現在のランディングパッドが現在の例外を受け入れることができるかどうかだけでなく、そのすべての親もチェックする必要があります。



タスクをもう少し簡単にしてみましょう。キャッチブロックが1つしかないランディングパッドを使用します。また、継承はありません。 しかし、どのようにして受け入れられたパッドタイプを見つけるのでしょうか？



一般に、これは.gcc_except_table部分にありますが、まだ分析していません：アクションテーブル。 throw.cppで逆アセンブルし、「try but dont catch」関数の呼び出しサイトテーブルのすぐ後にあるものを確認します。

 LLSDACSE1: .byte 0x1 .byte 0 .align 4 .long _ZTI14Fake_Exception .LLSDATT1:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くの情報があるようには見えませんが、例外の名前を持つ何かへの有望なポインターがあります。 _ZTI14Fake_Exceptionの定義を見てみましょう。

 _ZTI14Fake_Exception: .long _ZTVN10__cxxabiv117__class_type_infoE+8 .long _ZTS14Fake_Exception .weak _ZTS9Exception .section .rodata._ZTS9Exception,"aG",@progbits,_ZTS9Exception,comdat .type _ZTS9Exception, @object .size _ZTS9Exception, 11
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

非常に興味深いものが見つかりました！ 認識できますか？ これはstd :: Fake_Exception構造体のtype_infoです！



これで、例外に対する一種のリフレクションへのポインターを取得する方法があることがわかりました。 プログラムでこれを見つけることができますか？ さらに見てみましょう。

内部のC ++例外：例外タイプのリフレクションと読み取り.gcc_except_table

これで、ローカルデータストア.gcc_except_tableを読み取ることで、例外に関する多くの情報を取得できる場所がわかりました。 正しいランディングパッドを決定するために個人機能に実装する必要があるもの。



ABIの実装を放棄し、.gcc_except_tableのアセンブラー調査に突入して、処理可能な例外の種類を見つける方法を理解しました。 テーブルの一部に、必要な情報を含むタイプのリストが含まれていることがわかりました。 クリーンアップフェーズでこの情報を読み取りますが、最初に、LSDAヘッダーの定義を思い出してみましょう。

 struct LSDA_Header { uint8_t start_encoding; uint8_t type_encoding; //        uint8_t type_table_offset; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後のフィールドは、私たちにとって新しいものです。これは、タイプテーブルのオフセットを示します。 各呼び出しの定義も思い出してください。

 struct LSDA_CS { //         uint8_t start; //  ,    uint8_t len; // Landing pad uint8_t lp; //   action table + 1 (0  " ") uint8_t action; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後のフィールド「アクション」を見てください。 これは、アクションテーブルのオフセットです。 これは、特定のCS（呼び出しサイト）のアクションを見つけることができることを意味します。 トリックは、キャッチブロックがあるランディングパッドの場合、アクションにタイプテーブルへのオフセットが含まれていることです。オフセットを使用して、ヘッダーから取得できるタイプテーブルを取得できるようになりました。 話をやめて、コードをよく見てください：

 //     LSDA LSDA_ptr lsda = (uint8_t*)_Unwind_GetLanguageSpecificData(context); //   LSDA LSDA_Header header(&lsda); const LSDA_ptr types_table_start = lsda + header.type_table_offset; //  LSDA CS LSDA_CS_Header cs_header(&lsda); //    LSDA CS const LSDA_ptr lsda_cs_table_end = lsda + cs_header.length; //   action tables const LSDA_ptr action_tbl_start = lsda_cs_table_end; //  call site LSDA_CS cs(&lsda); // cs.action --  offset + 1;   cs.action == 0 //        const size_t action_offset = cs.action - 1; const LSDA_ptr action = action_tbl_start + action_offset; //  landing pad   catch the action table //   index   int type_index = action[0]; // types_table_start    ,   //    type_index.    ptr  // std::type_info,    catch- const void* catch_type_info = types_table_start[ -1 * type_index ]; const std::type_info *catch_ti = (const std::type_info *) catch_type_info; //    ,   -  Fake_Exception printf("%s\n", catch_ti->name());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、type_info構造を取得する前の間接的なアドレス指定が連続しているため複雑に見えますが、実際には複雑な処理は行わず、逆アセンブル時に見つかった.gcc_except_tableを読み取ります。



例外タイプの導出は、正しい方向への大きな一歩です。 また、私たちの個人的な機能も少し重なっています。 ほとんどのLSDAの読み取りの問題はカーペットの下に隠れている可能性があります。これはあまり高価ではないはずです（つまり、別の機能に配置する）。



さらに、処理される例外のタイプとスローされるタイプを比較する方法を学習します。

内部のC ++例外：適切なスタックフレームの取得

パーソナル関数の最新バージョンは、この例外を処理できるかどうかに関する情報の格納場所を知っています（ただし、1つのtry / catchブロックの1つのcatchブロックでのみ機能し、継承もありません）。最初に、例外が処理可能なタイプのものであるかどうかを確認します。



もちろん、最初に例外のタイプを見つける必要があります。 これを行うには、 __ cxa_throwが呼び出されたときに記録する必要があります。

 void __cxa_throw(void* thrown_exception, std::type_info *tinfo, void (*dest)(void*)) { __cxa_exception *header = ((__cxa_exception *) thrown_exception - 1); //       ,   _Unwind_ //          header->exceptionType = tinfo; _Unwind_RaiseException(&header->unwindHeader); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、パーソナル関数で例外の型を読み取り、型の一致を単純に比較できます（例外の名前はC ++行なので、単純な「==」で十分です）。

 //       const void* catch_type_info = lsda.types_table_start[ -1 * type_index ]; const std::type_info *catch_ti = (const std::type_info *) catch_type_info; //     __cxa_exception* exception_header = (__cxa_exception*)(unwind_exception+1) - 1; std::type_info *org_ex_type = exception_header->exceptionType; printf("%s thrown, catch handles %s\n", org_ex_type->name(), catch_ti->name()); // :      //   if (org_ex_type->name() != catch_ti->name()) continue;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

gitの最新の変更を見てください。



うーん、もちろん問題はありますが、自分で見つけられますか？ 例外が2つの段階でスローされ、最初の段階で例外を処理したい場合、2度目には再度処理したくないとは言えません。 _Unwindがこのケースを処理しますが、ドキュメントがないため、未定義の動作が発生する可能性が高いため、すべてを連続して処理するだけでは十分ではありません。



どのランディングパッドが例外を処理できるかを見つけるために個人的な機能を教えている限り、どの例外を処理できるかについてUnwindに嘘をつきました。代わりに、ABI 9ですべてを処理すると言います。真実はわかりません。処理するかどうか。 これは単なる修正です。次のようなことができます。

 _Unwind_Reason_Code __gxx_personality_v0 (...) { printf("Personality function, searching for handler\n"); // ... foreach (call site entry in lsda) { if (call site entry.not_good()) continue; //   landing pad   ;   //     ,  _Unwind_,    if (actions & _UA_SEARCH_PHASE) return _URC_HANDLER_FOUND; //      ,    _UA_CLEANUP_PHASE /*    */ return _URC_INSTALL_CONTEXT; } return _URC_CONTINUE_UNWIND; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パーソナル機能を起動すると、何が得られますか？ 秋！ 誰が疑うでしょう。 落下機能を覚えていますか？ 例外がキャッチするものは次のとおりです。

 void catchit() { try { try_but_dont_catch(); } catch(Fake_Exception&) { printf("Caught a Fake_Exception!\n"); } catch(Exception&) { printf("Caught an Exception!\n"); } printf("catchit handled the exception\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、私たちの個人的な機能は、ランディングパッドが処理できる最初のタイプのエラーのみをチェックします。 Fake_Exception catchブロックを削除して再試行すると、すべてが正しく機能します。 私たちの個人的な機能は、単一のcatchブロックを持つtry-catchブロックによって提供される正しいフレーム内の正しいcatchブロックを選択できます。



次の章では、再び改善します！

ボンネットの下のC ++例外：ランディングパッドから適切なキャッチを選択する

C ++の例外に関する第19章：LSDAを読み取り、適切なランディングパッド、適切なスタックフレームを選択して例外を処理できる個人用関数を作成しましたが、正しいcatchブランチを見つけることは依然として困難です。 作業用個人機能の最終バージョンでは、アクションテーブル.gcc_except_table全体で例外のタイプを確認する必要があります。



アクションテーブルを覚えていますか？ もう一度見てみましょう。ただし、いくつかのcatchブロックがあります。

 # Call site table .LLSDACSB2: # Call site 1 .uleb128 ip_range_start .uleb128 ip_range_len .uleb128 landing_pad_ip .uleb128 (action_offset+1) => 0x3 # Rest of call site table # Action table start .LLSDACSE2: # Action 1 .byte 0x2 .byte 0 # Action 2 .byte 0x1 .byte 0x7d .align 4 .long _ZTI9Exception .long _ZTI14Fake_Exception .LLSDATT2: # Types table start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例のランディングパッドでサポートされているすべての例外（catchit関数のこのLSDA）を読み取る場合は、次のようにする必要があります。

• 呼び出しテーブルからアクションのオフセットを取得します（忘れないでください、オフセット+ 1を読み取り、0はアクションなしを意味します）
• オフセットでアクション2に移動し、タイプ1のインデックスを取得します。タイプテーブルには逆の順序でインデックスが付けられます（つまり、末尾へのポインタがあり、-1 *インデックスを使用してアクセスする必要があります）
• types_table [-1]に移動して、Fake_Exceptionのtype_infoを取得します
• Fake_Exceptionはスローされた例外ではなく、次のアクション（アクション）（0x7d）へのオフセットを取得します
• uleb128で0x7dを読み取ると-3が返されます。これは、オフセットを読み取っている位置から3ステップ戻ります
• インデックス2の読み取りタイプ
• type_infoを取得して例外をスローしますが、今回は例外をスローします。これにより、ランディングパッドを設定できます。

再び多くの間接的なアドレス指定がある限り、複雑に見えますが、リポジトリで最終的なコードを見ることができます 。 型テーブルを読み取って必要なcatchブロックを決定できる個人関数の形でボーナスがあります（型がnullの場合、ブロックはすべての例外を連続して処理できます）。 面白い副作用があります。C++プログラムからスローされたエラーのみを処理できます。



最後に、例外がスローされる方法、スタックが解かれる方法、個人機能が正しいスタックフレームを選択する方法、およびランディングパッド内のブロックを選択する方法はわかっていますが、デストラクタを開始するという問題がまだあります。 それでは、RAIIサポートを提供することにより、個人の機能を変更します。

内部のC ++例外：プロモーションでのデストラクターの実行

ミニABIバージョン11は 、例外処理の基本機能のほとんどすべてに対応していますが、デストラクタを実行することはできません。 安全なコードを書きたい場合、これは非常に重要な部分です。 必要なデストラクタが.gcc_except_tableに格納されていることがわかっているため、アセンブラコードをもう少し見る必要があります。

 # Call site table .LLSDACSB2: # Call site 1 .uleb128 ip_range_start .uleb128 ip_range_len .uleb128 landing_pad_ip .uleb128 (action_offset+1) => 0x3 # Rest of call site table # Action table start .LLSDACSE2: # Action 1 .byte 0 .byte 0 # Action 2 .byte 0x1 .byte 0x7d .align 4 .long _ZTI14Fake_Exception .LLSDATT2: # Types table start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常のランディングパッドでは、アクションのインデックスのタイプが0より大きい場合、タイプテーブルにインデックスを取得し、それを使用して必要なcatchブロックを見つけることができます。 それ以外の場合、インデックスが0のとき、クリーンアップコードを実行する必要があります。 ランディングパッドが例外を処理できない場合でも、プロモーション中にクリーンアップを実行できます。 もちろん、クリーンアップが完了した後、ランディングパッドは_Unwind_Resumeを呼び出してプロモーションプロセスを続行する必要があります。



新しい最新バージョンのコードをgithubリポジトリにアップロードしましたが、悪いニュースがあります：uleb128 == charと言ったときの不正行為を覚えていますか？ デストラクタ用のコードの追加を開始すると、.gcc_except_tableのオフセットが大きくなり（「大きい」とは127を超えることを意味します）、トリックが機能しなくなりました。



次のバージョンでは、LSDAリーダーを書き換えて、uleb128コードを正しく処理する必要があります。



それにもかかわらず、私たちは目標を達成しました！ 彼らは、libcxxabiライブラリの助けなしに例外を正しく処理できるミニABIを作成しました！



もちろん、この言語のネイティブではない例外を処理したり、コンパイラとリンカー間の互換性をサポートしたりするなど、まだやることがあります。 たぶん後で...

内部のC ++例外：結果

低レベルの例外処理に関する20の章を読んだ後、在庫を確認しましょう！ 例外がどのようにスローされ、どのようにキャッチされるかについて、私たちは何を学びましたか？



おそらくこの記事の最大の部分である.gcc_except_tableの読み取りに関する恐ろしい詳細は別として、結論を出すことができます。

• C ++コンパイラは、実際には例外処理に関連する作業をほとんど行いません。ほとんどの魔法はlibstdc ++で発生します
• コンパイラが行ういくつかのことを次に示します。
  
  
  
  
  • CFIスタックプロモーション情報を作成します
  • ランディングパッドに関する情報を含む.gcc_except_tableと呼ばれるものを作成します（try / catchブロック）。 反射の一部。
  • throwを記述すると、コンパイラーはこれをlibstdc ++の2、3の呼び出しに変換し、例外を割り当ててからプロモーションを開始します
  
  
  
• ランタイムで例外がスローされると、__ cxa_throwはスタックプロモーションをlibstdcライブラリに委任します
• スタックプロモーションのプロセスでは、libstdc ++という特別な関数（パーソナリティ関数、パーソナリティルーチンと呼ばれる）が呼び出され、スタック内の各関数が例外を処理できるかどうかを確認します。
• 一致するcatchブロックが見つからない場合、std :: terminateが呼び出されます。
• 見つかった場合、スタックの昇格はスタックの先頭から再び開始されます。
• 2回目のパスでは、クリーニングが実行されます
• パーソナル関数は、現在のメソッドの.gcc_except_tableをチェックします。 クリーニングアクション（テーブル）がある場合、パーソナル関数は現在のスタックフレームに「ジャンプ」してこのメ​​ソッドのクリーニングを開始します
• アンワインダーは、この例外を処理できるスタックフレーム（関数を考慮）に遭遇するとすぐに、適切なcatchブロックにジャンプします
• catchブロックが実行されると、例外によって占有されていたメモリがクリアされます。

例外の処理方法を詳細に検討した結果、例外に対して安全なコードを記述することが非常に難しい理由を説明できるようになりました。



一見すると、例外は素晴らしく簡単に見えるかもしれませんが、少し深く掘り下げると、多くの困難に遭遇すると、プログラムは文字通りそれ自体を掘り下げ始めます（リフレクション）。これはC ++アプリケーションでは一般的ではありません。



例外がスローされるときに高レベル言語について話している場合でも、通常のコード実行の理解に頼ることはできません。通常、ifおよびswitchステートメントの形式で小さな分岐を使用して直線的に実行されます。例外を除いて、すべてが異なります。コードは理解できない順序で実行を開始し、スタックを拡張し、関数の実行を中断し、通常の規則に従うことを停止します。指示ポインターは各ランディングパッドで変化し、スタックは私たちの制御なしでスピンします。一般に、多くの魔法がボンネットの下で発生します。



結局、例外はプログラムの自然な実行に対する理解を損なうため複雑です。これは、それらを使用することを厳密に禁止されていることを意味するのではなく、それらを使用するときは常に注意する必要があるとだけ言っています！