ソース コードで動作する静的アナライザーもあれば、バイトコードで動作するものもあることに気付きました (FindBugs など)。オブジェクト コードで動作するものもあると思います。
私の質問は単純なものです。さまざまなレベルの分析に対してさまざまな種類の静的アナライザーを作成することの利点と欠点は何ですか?
「静的アナライザー」の下には、リンター、バグ ファインダー、さらには本格的な検証ツールも含まれています。また、分析のレベルごとに、ソース コード、高レベルの IR、低レベルの IR、バイトコード、オブジェクト コード、およびすべてのフェーズにアクセスできるコンパイラ プラグインを含めます。
これらのさまざまな側面は、アナライザーが作業を決定するレベルに影響を与える可能性があります。
静的アナライザーの設計は大変な作業です。Java (FindBugs)、.NET (Code Contracts に関連するさまざまなツール) など、バイトコードがソース プログラムの構造の大部分を保持している場合は特に、同じバイトコードにコンパイルされた複数の言語でこの作業を考慮しないのは残念です。場合によっては、共通のターゲット言語が分析目的で作成されましたが、コンパイル スキームはこのパスに従っていませんでした。
1 に関連して、最小数の構造を持つプログラムの正規化されたバージョンで静的アナライザーが動作する場合、静的アナライザーを作成するコストが少し低くなることを期待できます。静的アナライザーを作成するrepeat until場合、既に作成済みの場合の処理を作成する必要while doがあるのは面倒です。これら 2 つのケースでいくつかの関数を共有するようにアナライザーを構成することもできますが、これを処理する気楽な方法は、一方を他方に変換するか、ソースを一方のみを持つ中間言語に変換することです。
一方、Flash Sheridan の回答ですでに指摘されているように、ソース コードには最も多くの情報が含まれています。たとえば、セマンティクスが曖昧な言語では、ソース レベルのバグはコンパイルによって除去される場合があります。C および C++ には、誤って動作するプログラムを生成するなど、コンパイラが何でもできる「未定義の動作」が多数あります。バグが実行ファイルになければ、問題のあるバグではないと思うかもしれません。しかし、別のアーキテクチャー用に、またはコンパイラーの次のバージョンでプログラムを再コンパイルすると、バグが再び発生する可能性があります。これは、潜在的にバグを除去する可能性のあるフェーズの後に分析を行わない理由の 1 つです。
一部のプロパティは、コンパイルされたコードで妥当な精度でのみチェックできます。これには、Flash Sheridan によって再度指摘されたコンパイラに起因するバグがないことだけでなく、最悪の場合の実行時間も含まれます。同様に、多くの言語では、コンパイラによって生成されたアセンブリを見ない限り、浮動小数点コードが何をするのかを正確に知ることはできません (これは、既存のハードウェアがより多くを保証するのに便利ではないためです)。その場合、すべての可能性を考慮した不正確なソースレベル アナライザーを作成するか、浮動小数点プログラムの特定の 1 つのコンパイルを正確に分析するかを選択します (実行されるのは正確なアセンブリ コードであることが理解されている場合)。 .
もちろん、ソースコード分析が最も一般的に役立ちます。ヒューリスティックは、コメントやフォーマットを分析する必要がある場合もあります。ただし、GCCの誤動作によって発生したバグを検出する場合など、オブジェクトコードの分析も必要になる場合があります。GrammaTechの責任者でウィスコンシン州の教授であるThomasRepsは、数年前にスタンフォード大学でこれについて良い講演をしました：http: //pages.cs.wisc.edu/~reps/#TOPLAS-WYSINWYX。