🔗 课程链接：李樾老师和谭天老师的：

南京大学《软件分析》课程11（Pointer Analysis - Context Sensitivity I）_哔哩哔哩_bilibili

南京大学《软件分析》课程12（Pointer Analysis - Context Sensitivity II）_哔哩哔哩_bilibili

[第八章上下文敏感的指针分析](#第八章上下文敏感的指针分析)

[8.1 上下文敏感技术的介绍](#8.1 上下文敏感技术的介绍)

[8.1.1 为什么需要上下文敏感技术](#8.1.1 为什么需要上下文敏感技术)

[8.1.2 基本概念](#8.1.2 基本概念)

[1. 定义](#1. 定义)

[2. 策略------call-site sensitivity(call-string)](#2. 策略——call-site sensitivity(call-string))

[3. 实现------基于克隆的上下文敏感（Cloning-Based Context Sensitivity）](#3. 实现——基于克隆的上下文敏感（Cloning-Based Context Sensitivity）)

[4. Context-Sensitive Heap](#4. Context-Sensitive Heap)

[8.1.3 Context-Sensitive Heap的例子](#8.1.3 Context-Sensitive Heap的例子)

[8.2 规则 Rule](#8.2 规则 Rule)

[8.2.1 Domains and Notions 域与符号](#8.2.1 Domains and Notions 域与符号)

[8.2.2 Rules 规则](#8.2.2 Rules 规则)

[1. 处理4种基本语句的规则](#1. 处理4种基本语句的规则)

[2. 处理Call语句的规则](#2. 处理Call语句的规则)

[8.3 算法实现](#8.3 算法实现)

[8.3.1 Pointer Flow Graph with C.S.](#8.3.1 Pointer Flow Graph with C.S.)

[8.3.2 算法总体](#8.3.2 算法总体)

[8.3.3 ProcessCall的不同------Select上下文⭐](#8.3.3 ProcessCall的不同——Select上下文⭐)

[8.4 上下文敏感的变种](#8.4 上下文敏感的变种)

[8.4.1 从上下文敏感的视角，看上下文不敏感技术](#8.4.1 从上下文敏感的视角，看上下文不敏感技术)

[8.4.2 调用点敏感（Call-Site Sensitivity）](#8.4.2 调用点敏感（Call-Site Sensitivity）)

[8.4.3 对象敏感（Object Sensitivity）](#8.4.3 对象敏感（Object Sensitivity）)

[8.4.4 类型敏感（Type Sensitivity）](#8.4.4 类型敏感（Type Sensitivity）)

[8.4.5 总结](#8.4.5 总结)

第八章上下文敏感的指针分析

在第六章中介绍了上下文敏感的一些知识，这是提升指针分析精度最有效的技术，特别是对java。只要是跨函数涉及过程间的，基本都很有用。本章内容可能需要第六章和第七章的内容，再次贴一个之前的笔记连接：

8.1 上下文敏感技术的介绍

8.1.1 为什么需要上下文敏感技术

如下图所示的程序，如果进行上下文不敏感的常量传播分析，id被调用了两次，一次传入的是n1 一次是n2，就会导致 id 方法的参数 n 在不同上下文里的对象混在一起，指针域为{o1, o2}，再顺着指针分析传播的时候，通过返回值给x和y，会传递虚假的值，再分析 i 值的时候，会导致i = NAC

可

所以，上下文不敏感的技术（Imprecision of Context Insensitivity, C.I.），再处理一个方法的多个不同上下文的调用的时候，会混在一起传播，会引入假的数据流，丢失精度。

如果是上下文敏感的技术，如下，在不同的调用的时候，会进行标记，从而不会将所有参数的传递混在一起，这样分析出来的i 就是正确的值 1。

8.1.2 基本概念

1. 定义

上下文敏感（Context Sensitivity, C.S.）模型通过区分不同上下文的不同数据流来调用上下文以提高精度。

2. 策略------call-site sensitivity(call-string)

使用call-site sensitivity(call-string) 策略，将方法的每个上下文表示为一系列调用点（a chain of call sites），也就是对方法、caller、caller的caller的call site，通过一系列调用可以到达这个方法的call site 链，把这一系列call sites 当作上下文（是动态执行的调用栈的一个抽象）。

如下图所示，id(Number)的上下文，就是[1] 和 [2] 。

3. 实现------基于克隆的上下文敏感（Cloning-Based Context Sensitivity）

在基于克隆的上下文敏感指针分析中，会给每个方法加一个或多个上下文进行修饰。给方法加上下文，实际上就是给变量加上下文（变量在某方法中声明），可以当作对一个变量的标记，标记从哪个call-site过来。基本上，每个方法及其变量都是克隆的，每个上下文对应一个克隆。

如下图所示，对上述程序中的id 方法中的变量加上各自的上下文，以免混淆：

4. Context-Sensitive Heap

对于像Java这种OO语言，会频繁对对象进行操作，又因为这些对象经常分配在堆区，所以把这种频繁修改对象的行为称为heap-intensive。

对于heap-intensive，在实际中，为了提升精度，我们不仅要给变量加上下文，还要给对象加上下文（heap contexts），给对象的上下文来自于所在的方法。

加上堆抽象的上下文敏感技术提供了更精细的粒度堆模型。

8.1.3 Context-Sensitive Heap的例子

对下图代码，在采用上下文敏感的技术时，如果只考虑变量的上下文，不考虑Heap的上下文，对代码进行分析的结果如中间的表格所示，如果考虑heap、也考虑变量的上下文时候，分析结果如最右边：

对于第一种不考虑heap上下文的方法，实际上，在动态运行的时候，n是不会指向o2的。之所以会产生假的数据流，是因为这里的heap，在动态运行时，其实创建了两个o8，分别指向不同上下文中创建的两个对象x1 和 x2，然后又在o8处汇合了，一起传出去给n，导致了假的数据流。

在我们给对象加了上下文的时候，就可以有效地区分开，从而提升精度。对于变量和heap都是需要加上上下文来分析的。

8.2 规则 Rule

8.2.1 Domains and Notions 域与符号

|-----------------|-------------------------------|-----------------------------------------------------------------|
| 上下文 | c, c', c'' ∈ C | C表示程序中所有的上下文，具体的上下文用c, c'，c'' 表示 C里具体的内容为一系列call sites 形成的串（列表） |
| 上下文敏感的方法 | c: m ∈ C × M | 在具体的方法前，加上具体的上下文，表示上下文c之下的方法m |
| 上下文敏感的变量 | c: x, c': y ∈ C × V | |
| 上下文敏感的对象 | c: oi, c': oj ∈ C × O | |
| Fields | f, g ∈ F | Field 本身不需要加上下文，因为field挂靠在某个object上 |
| Instance fields | c: oi.f, c': oj.g ∈ C × O × F | 具体某个对象的field，需要加上具体的上下文的对象 |
| 上下文敏感的指针 | CSPointer = (C×V)∪(C×O×F) | 指针有两种，变量和field |
| 指向关系 | pt : CSPointer → 𝒫(C × O) | 即把上下文敏感的指针，映射到带有上下文的对象的幂集中。 |

8.2.2 Rules 规则

1. 处理4种基本语句的规则

如下图所示，就是上下文敏感下的指针分析处理4种语句的的规则，对比7.1.2中没有上下文敏感的规则，其实只多了红色的部分：上下文。（横线上的公式表示条件，横线下为结论）

感觉和7.1.2中的规则区别不大，这里就不再一条一条详细写了，可以对比下第七章的笔记：

【软件分析/静态分析】chapter7 课程09/10 指针分析基础（Pointer Analysis Foundations）_HiLittleBoat的博客-CSDN博客

2. 处理Call语句的规则

call 语句是很重要的，因为它决定你的上下文是如何产生的。具体的规则如下：

在7.4.2中处理没有上下文敏感的调用语句是，主要一般负责如下4件事情：

dispatch → 传递receive objects → 传参数 → 传返回值

加上上下文之后，主要区别有两点，

① 在dispatch找到目标方法m之后，要进行很关键的一步：Select，选择目标方法t的上下文

② 找到上下文之后，带着上下文信息，传receive object、参数、返回值，例如对于变量x 需要将 c': x，传到找到的目标方法的上下文里的m_this。

所以，在处理上下文敏感的调用语句的时候，主要负责如下5件事情：

dispatch → select → 传递特定上下文的receive objects → 传特定上下文的参数 → 传特定上下文的返回值

对于Select方法 ，主要是根据传入一系列参数（如下）来求目标方法的上下文，参数如下：

c：这个语句所在方法的上下文
l ：调用点，可以是这条语句的标签label，
c': oi ：receive object
m：目标方法

①先看一个例子：

这里，c为这些调用语句所在的方法/上下文，给Select传入一系列参数，选出第2行语句的目标方法 id(Number n) 的上下文是2，第3行的目标方法的上下文是3，然后跟目标函数组合在一起。

之后会对该方法进行克隆，有一个上下文就克隆一次，将针对特定上下文，传receive object(处理this语句)、传参、传返回值。

要注意，这里的例子中是可以用call site，也就是这个语句的label来进行表示上下文的，上下文也有其他的表示方法，具体怎么选，上下文用什么表示，会在8.3 算法实现部分介绍。

8.3 算法实现

8.3.1 Pointer Flow Graph with C.S.

我们用Pointer Flow Graph with C.S.(上下文敏感的指针流图)来表示对象在程序中指针之间的流动。他的组成如下：

Nodes：CSPointer = (C×V)∪(C×O×F)
一个节点可能表示++一个特定上下文的变量++ ，或++一个特定上下文抽象对象的一个field++ 。
于PFG相比，在上下文敏感的PFG中，每个节点都会带有上下文
Edges：CSPointer × CSPointer
一条边x→y，表示指针x所指向的对象可能流向y，并会被y所指向。

针对每条规则，形成的PFG边，具体可以比较7.2.2的PFG来看，如下：

8.3.2 算法总体

如下图所示为整个算法

实际上，如果没有加上那些上下文c、c'，就是一个上下文不敏感的指针分析。主体框架、思想和流程跟之前都是完全一致的，都是建立pfg，然后在pfg上传播指针的指向关系。其中AddEdge(s, t)和Propagate(n, pts)函数跟之前上下文不敏感的指针分析是完全一样的，代码就不在赘述。

主要区别有两点，即黄色高亮的地方：

① 给每个变量、函数、调用点等都加上了所在的上下文。

② 在处理调用的函数ProcessCall()函数中，增加了调用Select函数的部分。

这里主要阐述第二点不同，其他的地方就不再赘述了，可以参考上一篇chapter7 指针分析的笔记。

8.3.3 ProcessCall的不同------Select上下文⭐

上下文敏感的指针分析在处理调用语句的时候，会先根据流入的新对象oi，dispatch到真正的目标函数m，然后用select选出这个目标函数的上下文c^t。

主要根据以下信息来选择上下文（Select函数需要的参数）：

调用者x所在的上下文 c
调用点本身 l
流入调用者的新对象 c': oi
目标函数 m

不同的select定义的方式，取决于不同的上下文敏感的策略，在8.4中会介绍3种最常用的上下文敏感的策略，然后再详细介绍各自的select方法。

8.4 上下文敏感的变种

上下文的选取主要有：

call-site sensitivity
object sensitivity
Type sensitivity
......

8.4.1 从上下文敏感的视角，看上下文不敏感技术

上下文不敏感可以看作时上下文敏感的一个特殊情况，对于C.I.来说，Select函数在任何情况下都返回一个空的上下文，也就是在任何情况下都是一样的上下文

8.4.2 调用点敏感（Call-Site Sensitivity）

1. Call-Site Sensitivity原理

每个上下文由一系列调用链组成，在方法调用的时候，将调用点（call site）加入到caller的上下文中。实际上就是调用栈的抽象。

call-site sensitivity 也可以叫做call-string sensitivity，或k-CFA*

*论文出处：

Olin Shivers,1991. "Control-Flow Analysis of Higher-Order Languages".Ph.D. Dissertation. Carnegie Mellon University.

2. 例子

如下图所示，对于左边的程序，上下文如右边所示，每增加一次调用，就会加入一个新的上下文，但是对于15行有递归调用的情况，就可能会一直调用下去，导致context无限了。

所以，我们需要保证算法能够终止。再分析真实程序的时候，程序可能很复杂，调用链非常长，现在的静态分析没法解决这样的上下文。由此引入，k-Limiting Context Abstraction，来限制调用链的长度。

3. k-Limiting Context Abstraction

目的：
- 确保指针分析的终止
- 在现实世界的程序中，太多的上下文（长调用链）破坏了指针分析
方法：为上下文长度设置一个上限，用k表示
- 对于调用点敏感方法，每个上下文都由调用链的最后一个k call sites 组成
- 在实际应用中，k是一个小数目（通常是≤3）
- 方法上下文和堆上下文可以使用不同的k
  - 例如：k=2用于方法上下文，k=1用于堆上下文

4. k-Call-Site Sensitivity/k-CFA

① 1-call-site/1-CFA

如下图所示，当限制为1 的时候，对于每个上下文的调用链的长度只会去最后一个，第13行在第一次被9调用到的时候，上下文是[9]，之后第一次被15调用时，得到上下文[15]，之后再被15重复调用，就会只截取15，就不会再分析一次。

② 2-call-site/2-CFA

在实际应用中，我们会更倾向于用2层上下文，用调用的最后两个元素，来表示一个上下文。

5. 例子

① 1-call-site 例子

接下来，会结合8.3部分的算法（如下图所示），来具体分析一下下边的程序，为了简便，分析的过程中省去了heap的上下文和C.id里的this 变量，主要左下角的代码，最终目标是，分析第16行代码x.get() 会调用哪些方法。

首先，将一系列的数据结构(WL, PFG, S, RM, CG)初始化为空，

然后，使用AddReachable()方法，将加了上下文表示的方法，[ ]:C.main() ，加入RM，表示该方法可达，

然后，处理该main方法里的语句，这里有一个new语句，将其指针和对应heap对，<[ ]:c, {o3}>加入WL（这里的o3 先省略了上下文）

然后从WL中取出<[ ]:c, {o3}> ，处理过程跟c.i.是一样的，具体过程不再详细解释，这里把o3传到[ ]:c的指针集中，

然后需要根据ProcessCall()方法处理第4行，c的方法调用语句：

这里就涉及到了上下文敏感分析的关键一步：选取上下文 。这里即为第4行调用了C.m方法，这里C.m的上下文即为[4]，然后将<[4]:C.m_this, {o3}>传入WL中，然后连接CG，使用AddReachable()方法处理新可达的[4]:C.m方法，处理其new语句，再加入WL中，结果如下：

接下来，从WL中取出来<[4]:C.m_this, {o3}>，进行处理，同样，处理其相关语句，涉及14、15行的两个调用：

对于14，先选出来他的dispatch ，即7行的 C.id方法，接下来选择其上下文，即[14]，然后加调用边 [4]:14 → [14]:C.id(Number)，再往RM中添加方法 [14]:C.id(Number)。这个调用中涉及到了关键的传参和返回值 ：[4]:n1→[14]:n，及[14]:n→[4]:x。

对于15，同理，加调用边，加RM，处理传参和返回值，得到的结果如下图所示：

接着继续从WL中取出来未处理的pair，进行处理，这里不在详细介绍步骤，主要是沿着PFG，传递指针域。

对比c.i. ，上下文敏感的技术可以将不同上下文的节点区分开，最终结果如下图所示：

8.4.3 对象敏感（Object Sensitivity）

1. 原理

每个上下文都包含一个抽象对象列表（由他们的allocation sites表示）。

在方法调用时，使用接收对象及其heap context作为被调用上下文。
区分数据流在不同对象上的操作。

论文出处：

Ana Milanova,Atanas Rountev, and Barbara G.Ryder. " Parameterized ObjectSensitivity for Points-to and Side-Effect Analyses for Java".lSSTA 2002.

2. C.S.(1-Object) vs. C.S.(1-Call-site)

① 在如下例子中，对比1-call-site，1-object可以拿到准确的结果，如下图所示：

1-call-site方法会把doSet 混在一起

打个比方，就相当于，1-call-site 会一直记得从哪个屋子进来的，而1-object会一直记得记得这个人是谁。

② 但是对于以下的程序，1-Call-site会比1-object更准确：因为同一个receiver object 用不同参数多次调用了子函数，导致局部变量无法区分。

③ 总结：

综上，在理论上，这两种方法的精度是没有办法直接比较的。但是在实际应用中，对于像java的这种OO语言来说，对象敏感表现优于调用点敏感。

8.4.4 类型敏感（Type Sensitivity）