静态分析仪应分析哪些级别？

Question

我注意到一些静态分析器在源代码上运行，而其他静态分析器在字节码上运行（例如，FindBugs）。我确信甚至有一些可以处理目标代码。

我的问题很简单，为不同级别的分析编写不同类型的静态分析仪有哪些优点和缺点？

在“静态分析仪”下，我包括短号，错误发现者，甚至是完整的验证者。 通过分析级别，我将包括可访问所有阶段的源代码，高级IR，低级IR，字节码，目标代码和编译器插件。

Answer 1

这些不同的方面可能会影响分析仪决定工作的水平：

1. 设计静态分析器是一项很多的工作。遗憾的是，将这项工作用于将几种语言编译为相同的字节码是非常遗憾的，特别是当字节码保留了源程序的大部分结构时：Java（FindBugs），.NET（各种工具）与守则合约有关）。在some cases中，虽然编译方案没有遵循这条路径，但共同的目标语言是为了分析而编写的。

2. 与1相关，如果您的静态分析器在规范化版本的程序上工作且构造数量最少，则可能希望您的静态分析器编写成本稍低。在编写静态分析器时，在编写repeat until时必须编写while do的处理方法是一件麻烦事。您可以构建分析器，以便为这两种情况共享多个函数，但处理此问题的无忧处理方法是将一个函数转换为另一个，或者将源转换为仅包含其中一个的中间语言。 / p>

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

4. 某些属性只能在编译代码上以合理的精度检查。这包括Flash Sheridan再次指出的缺少编译器引入的错误，还包括worst-case execution time。类似地，除非您查看编译器生成的程序集，否则许多语言都不会让您知道浮点代码的确切行为（这是因为现有硬件不便于它们保证更多）。然后选择编写一个不精确的源级分析器，该分析器考虑所有可能性，或者精确分析浮点程序的一个特定编译，只要理解它是将执行的精确汇编代码即可。

Answer 2

当然，源代码分析是最常用的;有时，启发式甚至需要分析评论或格式。但你是对的，即使是对象代码分析也是必要的，例如，检测bugs introduced by GCC misfeatures。几年前，GrammaTech和威斯康星大学教授Thomas Reps在斯坦福大学就此发表了一篇很好的演讲：http://pages.cs.wisc.edu/~reps/#TOPLAS-WYSINWYX。