ロック、センパホア、マルチスレッドアプリケーションのバリアなどの同期操作を記録して、後でデバッグのために記録したアプリケーションを再生できるようにしたい。
途中で、独自のロック、センパフォア、条件変数などを提供します。ロギングも行う関数ですが、それらの下ではいくつかの一般的な同期操作を使用する必要があるため、これはやり過ぎだと思います。
したがって、私の質問は、プログラムに最小限の変更を加えるために、どの同期操作をログに記録する必要があるかということです。言い換えると、これらすべての同期操作が構築されるglibcおよびシステムコールの関数またはマクロはどれですか？ロギングとリプレイ用にのみ変更するようにします。
あなたの場合、Linuxでシステムコールを「ログに記録」する効果的な方法は、LD_PRELOADトリックを使用し、実際のシステムコールを、コールの使用をログに記録してからに転送する独自のバージョンのコールでオーバーライドすることです。実際のシステムコール。
より広範な例は、ここLinuxJournalにあります。
これらのリンクでわかるように、「トリック」の基本的な要点は、pthreadなどの他のシステムライブラリの前にシステムに独自のダイナミックライブラリをロードさせ、それらのライブラリ関数への呼び出しをマスクできることです。それらの関数の独自のバージョンを優先順位として配置することによって。次に、オーバーライドする関数内で、元の関数の使用をログに記録し、ログに記録しようとしている実際の呼び出しに引数を渡すことができます。
このメソッドの良いところは、完全にユーザーランドに残る関数とカーネル呼び出しを行う関数の両方で、実行できるほとんどすべての呼び出しをキャッチできることです。
私が考えることができる最善の方法は、「レコード」モードでgdbを使用してデバッグすることです。
このページによると：GDBプロセスレコードのスレッド化サポートは進行中ですが、まだ完了していない可能性があります。
あなたの質問にそれほど厳密に答えないでください、私は提案するかもしれません
他のプラットフォームには、他のいくつかのスレッドチェッカーが存在しますが、私はそれらについてあまり経験がありません。
したがって、GDBレコードモードはマルチスレッドをサポートしていませんが、RRレコード/再生システムは絶対にサポートしています：https ：//rr-project.org/ 。
技術的な制限が少ない商用ソリューションについては、UDBもあります：https ：//undo.io/solutions/ 。
私はここ数年デバッガーに取り組んできましたが、これまで見てきたことから、GDBレコード+リプレイは、この理由やその他の理由（たとえば、速度低下や大量のメモリ要件）のために、プライムタイムの準備ができていません。
開発環境で動作させることができれば、記録+再生/リバーシブルデバッグはワークフローにとってかなり画期的なものになる可能性があります。それを活用する方法を見つけていただければ幸いです。