【软件分析/静态分析】chapter8 课程11/12 指针分析—上下文敏感（Pointer Analysis - Context Sensitivity）
课程链接：李樾老师和谭天老师的：
南京大学《软件分析》课程11（Pointer Analysis - Context Sensitivity I）_哔哩哔哩_bilibili
南京大学《软件分析》课程12（Pointer Analysis - Context Sensitivity II）_哔哩哔哩_bilibili
目录
第八章 上下文敏感的指针分析
8.1 上下文敏感技术的介绍
8.1.1 为什么需要上下文敏感技术
8.1.2 基本概念
1. 定义
2. 策略——call-site sensitivity(call-string)
3. 实现——基于克隆的上下文敏感（Cloning-Based Context Sensitivity）
4. Context-Sensitive Heap
8.1.3 Context-Sensitive Heap的例子
8.2 规则 Rule
8.2.1 Domains and Notions 域与符号
8.2.2 Rules 规则
1. 处理4种基本语句的规则
2. 处理Call语句的规则
8.3 算法实现
8.3.1 Pointer Flow Graph with C.S.
8.3.2 算法总体
8.3.3 ProcessCall的不同——Select上下文⭐
8.4 上下文敏感的变种
8.4.1 从上下文敏感的视角，看上下文不敏感技术
8.4.2 调用点敏感（Call-Site Sensitivity）
8.4.3 对象敏感（Object Sensitivity）
8.4.4 类型敏感（Type Sensitivity）
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）
1. 原理
每个上下文都包含一个类型列表。在用方法调用时基于创建点所在的类型，作为被调用上下文。
是对 object sensitivity 的抽象，精度要弱于 object。
论文出处：
Yannis Smaragdakis, Martin Bravenboer, and Ondrej Lhotwk." Pick YourContexts Well: Understanding Object-Sensitivity".POPL 2011.
8.4.5 总结
精确度：object > type > call-site
效率：type > object > call-site
参考：
https://wenku.baidu.com/view/5cadf582de3383c4bb4cf7ec4afe04a1b071b0ad.html?_wkts_=1692682599401&bdQuery=%E4%B8%8A%E4%B8%8B%E6%96%87%E6%95%8F%E6%84%9F%E7%9A%84%E6%8C%87%E9%92%88%E5%88%86%E6%9E%90%E6%8A%80%E6%9C%AF