这写在Symbolic Execution的Wiki条目中，但是我找不到任何参考。谁能给我看看指针？谢谢。
这写在Symbolic Execution的Wiki条目中，但是我找不到任何参考。谁能给我看看指针？谢谢。
Answers:
我不了解有关符号执行与抽象解释之间比较的论文。我也不认为需要一个。阅读这两种技术的原始说明就足够了。
（相反，如果存在某些意外连接，那将是值得描述的。但是我非常怀疑是这种情况。）
符号执行的主要思想是，在执行的任意点，您都可以将所有变量的值表示为初始值的函数。抽象解释的主要思想是，您可以通过一系列过度逼近来系统地探索程序的所有执行。（我可以听到一些AI爱好者在前一个近似值中吟。）
因此，至少在原始表述中，符号执行与探索所有可能的执行无关。您甚至可以在标题中看到这一点：它包含单词“ testing”。但是这里有第8节的更多内容：“对于具有无限执行树的程序，符号测试不能穷举，也无法建立绝对正确性证明。”
相反，抽象解释旨在探索所有执行方式。为此，它使用了几种成分，其中一种与符号执行的主要思想非常相似。这些成分是（1）抽象状态，（2）连接和扩展（因此，标题中为“晶格”）。
抽象状态。程序在特定时间点的具体状态基本上是内存内容（包括程序代码本身和程序计数器）的快照。这有很多细节，很难跟踪。分析特定属性时，您可能希望忽略大部分具体状态。或者，您可能只想关心某个变量是负数，零值还是正数，而不关心其确切值。通常，您要考虑具体状态的抽象版本。为了解决这个问题，您必须具有可交换性属性：如果采用具体状态，执行一条语句，然后抽象结果状态，则应该获得与抽象初始状态相同的结果，然后执行相同的结果。陈述，但关于抽象状态。该可交换性图出现在两篇论文中。这是普遍的想法。同样，抽象解释更笼统，因为它并不指示如何抽象一个状态，它只是说应该有一种方法来实现。相反，符号执行表示您使用提及初始值的（符号）表达式。
加入和拓宽。如果程序执行以两种不同方式到达某个语句，则符号执行不会尝试合并这两种分析。这就是为什么上面的引用只讨论执行树，而不是讨论。但是，请记住，抽象解释要覆盖所有执行。因此，它要求一种在两个执行具有相同程序计数器的位置合并两个执行的分析的方法。（加入可以非常愚蠢（{a}加入{b} = {a，b}），以至于等于符号执行的作用。）通常，连接本身不足以保证您最终将完成对所有执行的分析。（特别是，前面提到的哑连接将不起作用。）考虑一个带有循环的程序：“ n = input（）；对于range（n）中的i：dostuff（）”。您应该循环几次并继续加入？没有固定答案。因此，还需要其他一些东西，并且正在扩大，这可以看作是一种启发式方法。假设您遍历了3次循环，并且了解到“ i = 0或i = 1或i = 2”。然后，您说：hmmm，...让我们扩大，您会得到“ i> = 0”。同样，抽象解释并没有说明如何进行扩展，而只是说明了必须解决哪些属性。
（很抱歉得到这么长的答案：我真的没有时间将其缩短。）
我认为这是非常肤浅的意思。抽象解释的第一步是确定具体的收集语义。收集语义不是描述单个状态的演变，而是描述状态集的演变。由于符号执行是关于状态集表示的原因，因此可以说它代表了程序的具体语义。我不知道正在制定更精确的信函。