这部分主要介绍几个Pin的用于注册回调函数的API：

对于每个注册函数的第二个参数val将在“回调”时传递给回调函数。如果在实际的场景中不需要传递第二个参数，为了保证安全，可以传递将val的值设置为0进行传递。val的理想使用方式是传递一个指向类实例的指针，这样回调函数在取消引用该指针前需要将其转换回一个对象。

所有的注册函数都会返回一个PIN_CALLBACK对象，该对象可以在后续过程中用于操作注册的回调的相关属性。

在注册函数返回PIN_CALLBACK对象后，可以使用PIN_CALLBACKAPI对其进行操作，来检索和修改在Pin中已注册的回调函数的属性。

声明：

函数：

CALLBACK_GetExecutionOrder()

声明：

作用：获取已注册回调函数的执行顺序。越靠前，越早被执行。

参数：callback，从*_Add*Funcxtion()函数返回的注册的回调函数

CALLBACK_SetExecutionOrder()

声明：

作用：设置已注册回调函数的执行顺序。越靠前，越早被执行。

参数：callback，从*_Add*Funcxtion()函数返回的注册的回调函数；order，新设置的回调函数的执行顺序。

PIN_CALLBACK_INVALID()

声明：

PIN回调的无效值。

CALL_ORDER是一个枚举类型，预定义了IARG_CALL_ORDER的值。其作用就是当指令有多个分析函数调用时，控制每个分析函数的调用顺序，默认值为CALL_ORDER_DEFAULT。

在进行数值设定时，可以使用类似CALL_ORDER_DEFAULT + 5的格式来设置。

针对在相同插桩回调环境中的针对同一指令的、具备同样CALL_ORDER的多个分析调用，Pin会按照插入的顺序进行调用。

虽然Pin的主要用途是对二进制程序进行插桩，但是它也可以实现对程序指令的修改。

最简单的实现方式是插入一个分析routine来模拟指令执行，然后调用INS_Delete()来删除指令。也可以通过直接或间接插入程序执行流分支（使用INS_InsertDirectJump和INS_InsertIndirectJump）实现，这种方式会改变程序的执行流，但是会更容易实现指令模拟。

INS_InsertDirectJump()

声明：

参数：

作用：插入相对于给定指令的直接跳转指令，与INS_Delete()配合使用可以模拟控制流转移指令。

INS_InsertIndirectJump()

声明：

参数：

作用：插入相对于给定指令的间接跳转指令，与INS_Delete()配合使用可以模拟控制流转移指令。

对于原始指令使用到的内存的访问，可以通过使用INS_RewriteMemoryOperand来引用通过分析routine计算得到的值来替代。

需要注意的是，对于指令的修改操作，会在所有的指令插桩操作完成后进行，因此在进行指令插桩时，插桩routine看到的都是原始的、没有经过修改的程序指令。

INS_RewriteMemoryOperand()

声明：

参数：

作用：更改此内存访问指令以饮用包含在给定特定寄存器中的虚拟内存地址。

在IA-32和Intel 64平台上，修改后的操作数仅使用具有新基址寄存器newBase的基址寄存器进行寻址。原始指令中该操作数的任何index， scale或者offset filed都会被删除。

该函数可以用于重写内存操作数，包括隐式的（如call、ret、push、pop），唯一不能重写的指令是第二个操作数大于0的enter。

newBase中的地址是中是该操作数将访问的最低地址，如果操作数在内存访问之前被指令修改，如push，则newBase中的值将不是堆栈指针，而是指令访问的内存地址。

用于内存地址重写的一个样例插桩代码如下：

命令行：

如下是Pin的命令行的完整option列表：

此外，还支持如下的tool options，它们需要跟在tool名字后面，但是要在--符号前：

IA-32和Intel(R) 64架构的Pin kit是一个组合kit，均包含32-bit和64-bit的版本。这就为复杂的环境提供了极高的可运行性，例如一个稍微有点复杂的运行如下：

需要注意的是：

选项-injection仅在UNIX平台下可以使用，该选项控制着Pin注入到目标程序进程的方式。

默认情况下，建议使用dynamic模式。在该模式下，使用的是对父进程注入的方式，除非是系统内核不支持。子进程注入方式会创建一个pin的子进程，所以会看到pin进程和目标程序进程同时运行。使用父进程注入方式时，pin进程会在注入完成后退出，所以相对来说比较稳定。在不支持的平台上使用父进程注入方式可能出现意料之外的问题。

Pin提供了将Pintool的messages写入到文件的机制——LOG() api，在合适的获取message的位置使用即可。默认的文件名为pintool.log，存储路径为当前工作目录，可以使用-logfile选项来改变log文件的路径和名字。

Pintool的开发质量会很大程度上决定tool的性能如何，例如在进行插桩时的速度问题。将通过一个例子来介绍一些提高tool性能的技巧。

首先是插桩部分代码：

然后是分析代码：

该工具的目的是计算控制流图中每个控制流变化的边界被遍历的频率。工作原理如下：插桩组件通过调用docount2对每个分支进行插桩。传入的参数为源分支和目标分支以及分支是否被执行。源分支和目标分支代表来控制流边界的源和目的。如果没有执行分支，控制流不会发生改变，因此分析routine会立即返回。如果执行了分支，就使用src和dst参数来查找与此边界相关的计数器，并增加计数器的值。

Shifting Computation for Analysis to Instrumentation Code

在一个典型的应用程序中，大概每5条指令构成一个分支，在这些指令执行时会调用Lookup函数，造成性能下降。我们思考这个过程可以发现，在指令执行时，每条指令只会调用一次插桩代码，但会多次调用分析代码。所以，可以想办法将计算工作从分析代码转移到插桩代码，这样就可以降低调用次数，从而提升性能。

首先，就大多数分支而言，我们可以在Instruction()中找到目标分支。对于这些分支，我们可以在Instruction()内部调用Lookup()而不是docount2()，对于相对较少的间接分支，我们仍然需要使用原来的方法。

因此，我们增加一个新的函数docount，原来的docount2函数保持不变：

相应地，修改插桩函数：

在插桩函数内部根据不同的情况，执行不同的分析代码，避免对所有类型的指令都笼统地调用性能要求高docount2函数。

最终实现的完整代码如下：

上面新增的docunt()函数的代码十分简洁，极大地提升了性能。除此之外，还可以被Pin内联，进一步避免函数调用的开销。

但是现在的docount()函数中存在控制流，这有可能在进行内联时发生未知的改变。最好的解决办法是去掉函数中的控制流，这样进行内联时可以保证健壮性。

考虑到docount()函数的'taken'参数要么为0，要么为1，所以可以将函数代码修改为如下：

如此修改后，docunt()函数就可以进行内联了，并且可以保证函数的健壮性。

在某些情况下，我们不关心具体在什么位置进行插桩，只要保证插桩代码位于基本块内部即可。在这种情况下，我们可以将插桩位置的选择权交给Pin自身，Pin可以选择需要最少寄存器进行保存和恢复的插入点，提升性能。

一个样例如下：

这里IPOINT是一个枚举类型，决定了分析call被插入到什么地方。插入的对象可以是：INS，BBL，TRACE，RTN，其完整可用的值如下：

对于一些比较“小”的函数来说，对函数的调用开销有时与函数自身的运算开销基本相同，因此一些编译器会提供一些调用链接优化机制来降低开销。例如，IA-32下的gcc有一个在寄存器中传递参数的regparm属性。

Pin中有一定数量的备用链接，使用PIN_FAST_ANALYSIS_CALL来声明分析函数即可使用，而插桩函数InsertCall则需要使用IARG_FAST_ANALYSIS_CALL。如果二者只更改了一个，那么就可能出现传参错误。例如前面给出的源码例子就使用了fast call linkages：

在对比较复杂的大型函数使用该方法时，效果并不明显，但不会造成性能的下降。

第二个调用链接优化是消除帧指针。如果使用gcc，则推荐加上"-fomit-frame-pointer"选项。Pin官方的标准Pintool的makefile包括该选项。与PIN_FAST_ANALYSIS_CALL一样，该选项对“小”函数的效果比较明显。需要注意的是，debugger会根据帧指针来显示堆栈回溯情况，所以如果想调试Pintool的话，就不要设置该选项。如果使用标准的Pintool的makefile来进行变异，则可以通过修改OPT选项来进行改变：

Pin通过自动内联没有控制流变化的分析routine来提升插桩性能。但是有很多分析routine是有控制流的，最典型的就是有一个简单的“if-then”的条件语句，它只会执行少量的分析代码，并“then”部分只执行一次。为了将这类的语句转换为常规的没有控制流变化的语句，Pin提供了一些插桩API来重写分析routine。下面是一个重写的例子：

例如我们当前想要实现的一个分析routine的代码如下：

在原始的IpSample()函数中有一个明显的条件语句，会存在控制流的变化。如何消除该条件控制流的存在呢？

可以看到分析routine内部其实可以拆解为2部分功能：icount的自减和“if”语句，那么可以使用两个单独的函数实现。而且，前者比后者的执行频率要更高。拆解后的代码如下：

一个完整的实现消除控制流变化的代码如下：

使用条件插桩API INS_InsertIfCall()和INS_InsertThenCall()来告诉Pin只有当CountDown()执行结果非0时，才执行PrintIp()。这样一来，CountDown()函数就可以内联在Pin中，对于没有内联的PrintIp()则只有在满足条件时才会执行一次。

INS_InsertThenCall()插进去的函数只有在INS_InsertIfCall()插进去的函数返回非0值时才会执行。这个功能可以说是一个十分巧妙的功能。

在开发自己的Pintool时，可以copy一份example目录， 然后在makefile.rules文件中添加上自己的tool，可以以最简单的MyPinTool为模版。

如果直接修改MyPinTool，并且没有特殊的编译需求，则直接使用默认配置就好。如果要新增tool或者需要指定特殊的构建标志，则需要修改makeifile.rules文件。

构建YourTool.so(源文件为YourTool.cpp)：

如果想编译成IA-32架构，则使用“obj-ia32”替换“obj-intel64”即可。

copy文件夹MyPinTool到指定位置子，然后编辑makefile.rules文件。

要更改将创建工具的目录，可以从命令行覆盖 OBJDIR 变量：

目录source/tools/Config中存放了make配置的基本文件，不要轻易修改这些文件，可以基于其中的模版文件进行更新。

下面对其中的几个关键文件进行说明：

source/tools目录下的每个测试性质的目录中都包含makefile链中的两个文件：

下面介绍如何通过makefile构建二进制程序并运行测试。以下描述的变量都在makefile.rules文件的"Test targets"部分进行描述：

默认使用的构建规则是source/tools/Config/makefile.default.rules，输入为单一的c/cpp文件，生成相同名字的二进制程序。如果输入为多个源文件，且需要自定义构建规则，可以在make.rules文件的"Build rules"部分的末尾添加。如下是规则例子：

构建单一源文件且不进行优化：

构建多源文件且进行优化：

在"Test recipes"部分自定义自己的测试需求，例如：

摘取makefile.config中几个重点的标志进行说明：

IN_ROOT：在套件外构建工具时指定Pin套件的位置。
CC: 指定工具的默认c编译器。
CXX：指定工具的默认c++编译器
APP_CC：指定应用程序的默认 c 编译器。如果未定义，APP_CC 将与 CC 相同。
APP_CXX：指定应用程序的默认 c++ 编译器。如果未定义，APP_CXX 将与 CXX 相同。
TARGET：指定默认目标架构，例如交叉编译。
ICC: 使用英特尔编译器构建工具时指定 ICC=1。
DEBUG: 当指定 DEBUG=1 时，在构建工具和应用程序时会生成调试信息。此外，不会执行任何编译和/或链接优化。

本篇结束后理论部门就基本结束了，后续将开始进行实践。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！