すべてではありませんが、ほとんどのパッケージをコンパイルしている間、stdoutとstderrの出力は複数の個別のプロセスによって生成され、ビルド中に処理/変更/生成されたファイルもさまざまなプロセスで処理されます。これは、(おそらくほとんどの)パッケージビルドシステムが最終ビルド結果を生成するためにいくつかのソフトウェアフラグメントに依存しているためです。
Linux(またはBSD)でビルドプロセスを透過的に追跡して次の情報を取得できる場合は、非常に便利です。
- どのプロセスがstdoutとstderrにどの情報を生成したか(そしてそのプロセスの先祖は何ですか)
- ファイルを読み取るプロセス
- どのプロセスがファイルに書き込まれていますか?
この情報は次の点に役立ちます。
- 並列に実行されるビルドに対しても線形化されたビルドログを生成する
- 入力ソースファイルを出力バイナリに自動的に関連付けることができます。
- 埋め込みコードのコピー検出
- GPL準拠の確認
- 生成されたバイナリにどのライセンスが適用されているかを確認します(生成にどのソースファイルが使用されているかを知っているため)。
プログラムの実行を追跡するもう1つの方法は、ファイルを作成または変更する各プログラムを変更し、すべてのマシンが読み取り可能な均一な出力形式を持つようにすることです。ソフトウェアのコンパイル(さまざまな言語用のコンパイラ、ドキュメントジェネレータ、イメージコンバータ、さらにはsed、grep、cp、mvなどのUnixコマンド)に関連するプログラムの数を考慮すると、これは実現できません。
Linuxは、プロセスとすべての子プロセスで行われたすべてのシステムコールを追跡するためのいくつかの方法を提供します。ただし、ptrace または LD_PRELOAD ベースのメカニズムは一部のビルドに影響を及ぼし、2 つの方法のいずれかで追跡されない場合とは失敗したり、他の結果が生成されます。 systemtap は手動でのみリッスンし、イベントが早すぎる場合でもプロセスを遅くしないため、通常は検索をスキップします。
だから私は、プロセスとすべての子に完全に透明な方法で(実行時間に影響を与える可能性があることを除いて)、プロセスとすべての子が実行したシステムコールを確実に追跡する方法を探しています。
Linux(またはBSD)でこれは可能ですか?それではどうですか?