static-analysis - 静态分析器应该分析什么级别？

Question

我注意到一些静态分析器在源代码上运行，而另一些在字节码上运行（例如，FindBugs）。我敢肯定，甚至有一些适用于目标代码。

我的问题很简单，为不同级别的分析编写不同种类的静态分析器有什么优缺点？

在“静态分析器”下，我包括了 linter、bug finder，甚至是成熟的验证器。通过分析级别，我将包括源代码、高级 IR、低级 IR、字节码、目标代码和可以访问所有阶段的编译器插件。

Answer 1

这些不同的方面可以影响分析器可能决定工作的级别：

1. 设计静态分析器需要做很多工作。不考虑编译成相同字节码的几种语言的这项工作将是一种耻辱，特别是当字节码保留源程序的大部分结构时：Java（FindBugs）、.NET（与代码合同相关的各种工具）。在某些情况下，为了分析目的而编写了通用目标语言，尽管编译方案并未遵循此路径。

2. 与 1 相关，您可能希望您的静态分析器在具有最少构造数的程序的规范化版本上工作时，其编写成本会更低一些。在编写静态分析器repeat until时，必须为已经编写的处理编写处理while do是一件麻烦事。您可以构建您的分析器，以便为这两种情况共享几个功能，但处理这种情况的轻松方法是将一个翻译成另一个，或者将源翻译成只有其中一个的中间语言。

3. 另一方面，正如 Flash Sheridan 的回答中已经指出的那样，源代码包含的信息最多。例如，在语义模糊的语言中，源代码级别的错误可以通过编译来消除。C 和 C++ 有许多“未定义的行为”，允许编译器做任何事情，包括生成一个意外运行的程​​序。好吧，你可能会想，如果错误不在可执行文件中，它就不是有问题的错误。但是，当您为其他架构或使用下一版本的编译器重新编译程序时，错误可能会再次出现。这是在任何可能消除错误的阶段之后不进行分析的原因之一。

4. Some properties can only be checked with reasonable precision on compiled code. That includes absence of compiler-introduced bugs as pointed out again by Flash Sheridan, but also worst-case execution time. Similarly, many languages do not let you know what floating-point code does precisely unless you look at the assembly generated by the compiler (this is because existing hardware does not make it convenient for them to guarantee more). The choice is then to write an imprecise source-level analyzer that takes into account all possibilities, or to analyze precisely one particular compilation of a floating-point program, as long as it is understood that it is that precise assembly code that will be executed.

Answer 2

当然，源代码分析是最有用的；有时启发式甚至需要分析注释或格式。但是您是对的，即使是目标代码分析也可能是必要的，例如，检测GCC misfeatures 引入的错误。几年前，GrammaTech 负责人兼威斯康星州教授 Thomas Reps 曾在斯坦福大学就此发表了精彩的演讲：http: //pages.cs.wisc.edu/~reps/#TOPLAS-WYSINWYX。