3.1。客户端请求机制

RUNNING_ON_VALGRIND：

如果在Valgrind上运行，则返回1，如果在实际CPU上运行则返回0。如果您运行Valgrind本身，则返回您运行的Valgrind仿真层数。

VALGRIND_DISCARD_TRANSLATIONS：

丢弃指定地址范围内的代码翻译。如果您正在调试JIT编译器或其他动态代码生成系统，则很有用。在此调用之后，尝试在无效地址范围内执行代码将导致Valgrind对该代码进行新的翻译，这可能是您想要的语义。请注意，代码无效是昂贵的，因为快速找到所有相关的翻译是非常困难的，所以尽量不要经常打电话。请注意，您可以很聪明：只有当以前包含代码的区域被新的代码覆盖时，才需要调用它。您可以选择将代码写入新鲜的内存，并且偶尔调用这些代码一次丢弃大量的旧代码。

或者，对于ppc32 --smc-check=all/ Linux，ppc64 / Linux或ARM / Linux 的透明自修改代码支持，使用或运行。

VALGRIND_COUNT_ERRORS：

返回Valgrind到目前为止发现的错误数。与--log-fd=-1选项结合使用时，可用于测试工具代码 ; 这个默认运行Valgrind，但客户端程序可以检测何时发生错误。仅对报告错误的工具有用，例如它对Memcheck有用，但对于Cachegrind，它总是返回零，因为Cachegrind不报告错误。

VALGRIND_MALLOCLIKE_BLOCK：

如果您的程序管理自己的内存，而不是使用标准的malloc/ new/ new[]，则跟踪有关堆块的信息的工具不会做得很好。例如，Memcheck将不会检测到几乎相同的错误，并且错误消息将不会提供信息。为了改善这种情况，在您的自定义分配器分配一些新内存之后使用此宏。有关valgrind.h如何使用它的信息，请参阅注释 。

VALGRIND_FREELIKE_BLOCK：

这应该与之配合使用 VALGRIND_MALLOCLIKE_BLOCK。再次看看valgrind.h有关如何使用它的信息。

VALGRIND_RESIZEINPLACE_BLOCK：

通知Valgrind工具，分配的块的大小已被修改，但不是其地址。查看valgrind.h有关如何使用它的更多信息。

VALGRIND_CREATE_MEMPOOL， VALGRIND_DESTROY_MEMPOOL， VALGRIND_MEMPOOL_ALLOC， VALGRIND_MEMPOOL_FREE， VALGRIND_MOVE_MEMPOOL， VALGRIND_MEMPOOL_CHANGE， VALGRIND_MEMPOOL_EXISTS：

这些类似于 VALGRIND_MALLOCLIKE_BLOCK和 VALGRIND_FREELIKE_BLOCK ，但偏向于使用内存池的代码定制。有关详细说明，请参阅 内存池。

VALGRIND_NON_SIMD_CALL[0123]：

在客户端程序中执行实际 CPU 上的功能 ，而不是Valgrind正常运行代码的虚拟CPU。该函数必须采用一个整数（保持线程ID）作为第一个参数，然后将0,1,2或3个参数（取决于使用哪个客户端请求）。这些在Valgrind内部以各种方式使用。它们可能对客户端程序有用。

警告：只有使用这些，如果你 真的知道你在做什么。它们并不完全可靠，可能导致Valgrind崩溃。查看 valgrind.h更多详情。

VALGRIND_PRINTF(format, ...)：

将Printf样式的消息打印到Valgrind日志文件。该消息以一对**标记之间的PID为前缀 。（与所有客户端请求一样，如果客户端程序未在Valgrind下运行，则不会输出任何内容。）直到遇到换行符或后续的Valgrind输出打印时才会产生输出; 这允许您通过多个呼叫建立单行输出。返回输出的字符数，不包括PID前缀。

VALGRIND_PRINTF_BACKTRACE(format, ...)：

喜欢VALGRIND_PRINTF（特别是返回值是相同的），但是之后立即打印一个堆栈回溯。

VALGRIND_MONITOR_COMMAND(command)：

执行给定的monitor命令（一个字符串）。如果识别到命令，则返回0。如果无法识别命令，则返回1。请注意，某些监视器命令提供对通过特定客户端请求可访问的功能的访问。例如，可以使用VALGRIND_DO_LEAK_CHECK或通过监视器命令“leak_search”从客户端程序请求memcheck泄漏搜索。请注意，命令字符串的语法仅在运行时验证。因此，如果存在，最好使用特定的客户端请求对参数进行更好的编译时验证。

VALGRIND_STACK_REGISTER(start, end)：

注册一个新的堆栈。通知Valgrind，start和end之间的内存范围是唯一的堆栈。返回可与其他VALGRIND_STACK_*调用一起使用的堆栈标识符 。

Valgrind将使用此信息来确定堆栈指针的更改是否是推送到堆栈上的项目或更改为新堆栈。如果您正在使用用户级线程包，并注意到堆栈跟踪记录中的崩溃或Valgrind关于未初始化内存读取的虚假错误，请使用此方法。

警告：不幸的是，这个客户端请求是不可靠的，最好避免。

VALGRIND_STACK_DEREGISTER(id)：

取消注册以前注册的堆栈。通知Valgrind以前注册的堆栈ID的内存范围 id不再是堆栈。

警告：不幸的是，这个客户端请求是不可靠的，最好避免。

VALGRIND_STACK_CHANGE(id, start, end)：

更改以前注册的堆栈。通知Valgrind，堆栈id的先前注册的堆栈 id已更改其起始值和结束值。如果您的用户级线程包实现堆栈增长，请使用此选项。

警告：不幸的是，这个客户端请求是不可靠的，最好避免。

3.2。使用Valgrind gdbserver和GDB调试程序

开始使用最简单的方法是使用标志运行Valgrind --vgdb-error=0。然后按照屏幕上的方向进行操作，这样您就可以获得启动GDB并将其连接到程序所需的精确命令。

否则，这里有一个更详细的概述。

如果要在使用Memcheck工具时使用GDB调试程序，请启动Valgrind，如下所示：

valgrind --vgdb = yes --vgdb-error = 0 prog

在另一个shell中，启动GDB：

gdb程序

然后给GDB发送以下命令：

（gdb）target remote | vgdb

您现在可以调试程序，例如插入断点，然后使用GDB continue 命令。

这个快速启动信息足以基本使用Valgrind gdbserver。以下部分描述了Valgrind和GDB组合提供的更高级的功能。请注意，--vgdb=yes可以省略命令行标志，因为这是默认值。

GNU GDB调试器通常用于调试在同一台机器上运行的进程。在这种模式下，GDB使用系统调用来控制和查询被调试的程序。这样做很好，但只允许GDB调试在同一台计算机上运行的程序。

GDB还可以调试在不同计算机上运行的进程。为了实现这一点，GDB定义了一个协议（即一组查询和回复数据包），有助于获取内存或寄存器的值，设置断点等。gdbserver是“GDB远程调试”协议的实现。要调试在远程计算机上运行的进程，gdbserver（有时称为GDB存根）必须在远程计算机端运行。

Valgrind内核提供了一个内置的gdbserver实现，它使用--vgdb=yes 或激活--vgdb=full。该gdbserver允许在Valgrind的合成CPU上运行的进程远程调试。GDB向Valgrind嵌入式gdbserver发送协议查询数据包（如“获取寄存器内容”）。gdbserver执行查询（例如，它将获得合成CPU的寄存器值），并将结果返回给GDB。

GDB可以使用各种通道（TCP / IP，串行线等）与gdbserver进行通信。在Valgrind的gdbserver的情况下，通过一个管道和一个名为vgdb的小帮助程序完成通信，该程序充当中间人。如果没有使用GDB，vgdb也可以用于从shell命令行将监控命令发送到Valgrind gdbserver。

要调试程序“ prog” Valgrind的下运行，你必须确保Valgrind的gdbserver的是通过指定激活--vgdb=yes 或--vgdb=full。辅助命令行选项， --vgdb-error=number可以用于告知gdbserver在显示指定数量的错误后才会变为活动状态。因此，值为零将导致gdbserver在启动时变为活动状态，这允许您在开始运行之前插入断点。例如：

valgrind --tool = memcheck --vgdb = yes --vgdb-error = 0 ./prog

Valgrind gdbserver在启动时被调用，并指示它正在等待来自GDB的连接：

== 2418 == Memcheck，一个内存错误检测器
== 2418 ==版权所有（C）2002-2010和GNU GPL'd，由Julian Seward等人
== 2418 ==使用Valgrind-3.7.0.SVN和LibVEX; 用-h重新运行版权信息
== 2418 ==命令：./prog
== == 2418
== 2418 ==（启动时的动作）vgdb me ...

然后可以将GDB（在另一个shell中）连接到Valgrind gdbserver。为此，必须在程序上启动GDB prog：

gdb ./prog

然后，您向GDB指出您要调试远程目标：

（gdb）target remote | vgdb

GDB然后启动一个vgdb中继应用程序与Valgrind嵌入式gdbserver进行通信：

（gdb）target remote | vgdb
远程调试使用| vgdb
在gdb和进程2418之间中继数据
从/lib/ld-linux.so.2...done读取符号。
从/usr/lib/debug/lib/ld-2.11.2.so.debug...done读取符号。
/lib/ld-linux.so.2的加载符号
[切换到线程2418]
来自/lib/ld-linux.so.2的_start（）中的0x001f2850
（GDB）

请注意，vgdb是作为Valgrind分发的一部分提供的。您不需要单独安装。

如果vgdb检测到可以连接多个Valgrind gdbservers，它将列出所有这些服务器及其PID，然后退出。然后，您可以重新发行GDB“目标”命令，但指定要调试的进程的PID：

（gdb）target remote | vgdb
远程调试使用| vgdb
没有--pid = arg给定和多个valgrind pids找到：
使用--pid = 2479 for valgrind --tool = memcheck --vgdb = yes --vgdb-error = 0 ./prog
使用--pid = 2481 for valgrind --tool = memcheck --vgdb = yes --vgdb-error = 0 ./prog
使用--pid = 2483 for valgrind --vgdb = yes --vgdb-error = 0 ./another_prog
远程通信错误：资源暂时不可用。
（gdb）target remote | vgdb --pid = 2479
远程调试使用| vgdb --pid = 2479
在gdb和进程2479之间中继数据
从/lib/ld-linux.so.2...done读取符号。
从/usr/lib/debug/lib/ld-2.11.2.so.debug...done读取符号。
/lib/ld-linux.so.2的加载符号
[切换到线程2479]
来自/lib/ld-linux.so.2的_start（）中的0x001f2850
（GDB）

一旦GDB连接到Valgrind gdbserver，它就可以像你在本机调试程序一样使用：

等等。有关GDB功能的完整说明，请参阅GDB用户手册。

开发Android应用程序时，通常会使用开发系统（安装了Android NDK）来编译应用程序。将使用Android目标系统或仿真器来运行应用程序。在此设置中，Valgrind和vgdb将在Android系统上运行，而GDB将在开发系统上运行。GDB将使用Android NDK'adb forward'应用程序连接到在Android系统上运行的vgdb。

示例：在Android系统上，执行以下操作：

valgrind --vgdb-error = 0 --vgdb = yes prog
然后在另一个shell中运行：
vgdb --port = 1234

在开发系统中，执行以下命令：

adb forward tcp：1234 tcp：1234
gdb程序
（gdb）target remote：1234

GDB将使用本地tcp / ip连接来连接到Android adb转发器。Adb将在主机系统和Android目标系统之间建立中继连接。确保使用Android NDK系统中提供的GDB（通常是arm-linux-androideabi-gdb），因为主机GDB可能无法调试Android手臂应用程序。请注意，本地端口nr（由GDB使用）不一定等于vgdb使用的端口号：adb可以在不同端口号之间转发tcp / ip。

在当前版本中，默认情况下，由于建立一个合适的目录，因为Valgrind可以创建必要的FIFO（命名管道）用于通信目的，GDB服务器未启用。您可以尝试使用GDB服务器，但是您需要使用该标志--vgdb=yes或 显式启用它 --vgdb=full。

此外，您将需要选择一个临时目录（a）可由Valgrind写入，（b）支持FIFO。这是难点。通常/sdcard满足要求（a），但是（b）因为是VFAT文件系统而VFAT不支持管道而失败。可能你可以尝试是 /data/local， /data/local/Inst（如果你安装了Valgrind的存在），或者 /data/data/name.of.my.app，如果你正在运行特定的应用程序，它有它自己的这种形式的目录。这最后的可能性可能是最高的成功概率。

您可以通过--with-tmpdir=配置时间标志指定临时目录或在运行Valgrind时（在Android设备上，而不是Android NDK开发主机上）设置环境变量TMPDIR。另一个选择是使用--vgdb-prefix=Valgrind命令行选项来指定FIFO的目录。

我们希望将来有一个更好的故事，用于Android上的临时目录处理。困难在于，与标准Unixes不同，没有单个临时文件目录可靠地在所有设备和方案中工作。

Valgrind gdbserver通过“monitor命令”提供了额外的Valgrind特定功能。这样的监视命令可以从GDB命令行或从shell命令行发送，或者由客户端程序使用VALGRIND_MONITOR_COMMAND客户端请求发送。有关Valgrind核心监视器命令的列表，请参阅 Valgrind监视器命令，无论选择了Valgrind工具。

以下工具提供特定于工具的监视器命令：

特定于工具的监视器命令的示例是Memcheck监视器命令leak_check full reachable any。这要求对所分配的内存块进行全面报告。要执行此泄漏检查，请使用GDB命令：

（gdb）monitor leak_check完全可达任何

GDB将发送leak_check 命令到Valgrind gdbserver。如果Valgrind gdbserver将其识别为Valgrind core monitor命令，则会自动执行monitor命令。如果它不被认可，则假设它是具体的工具，并被交给该工具执行。例如：

（gdb）monitor leak_check完全可达任何
== 2418 == 1块中的100字节仍然可以在损失记录1中1
== 2418 == at 0x4006E9E：malloc（vg_replace_malloc.c：236）
== 2418 == by 0x804884F：main（prog.c：88）
== == 2418
== 2418 == LEAK SUMMARY：
== 2418 ==绝对丢失：0块0块
== 2418 ==间接丢失：0个字节，0个块
== 2418 ==可能丢失：0个字节的0个块
== 2418 ==仍然可达：100个字节的1个块
== 2418 == suppress：0个字节，0个块
== == 2418
（GDB）

与其他GDB命令一样，Valgrind gdbserver将接受缩写的监视器命令名称和参数，只要给定的缩写是明确的。例如，上述 leak_check 命令也可以键入：

（gdb）mo lfra

这些字母mo被GDB识别为缩写monitor。所以GDB将字符串发送l f r a到Valgrind gdbserver。这个字符串中提供的字母对Valgrind gdbserver来说是明确的。因此，这将给出与未缩写的命令和参数相同的输出。如果提供的缩写不明确，则Valgrind gdbserver会报告可匹配的命令列表（或参数值）：

（gdb）mo v。n
v。可以匹配v.set v.info v.wait v.kill v.translate v.do
（gdb）mo vi n
n_errs_found 0 n_errs_shown 0（vgdb-error 0）
（GDB）

而不是从GDB发送监视器命令，您也可以从shell命令行发送这些命令。例如，以下命令行在shell中给出时，将导致进程3145执行相同的泄漏搜索：

vgdb --pid = 3145 leak_check完全可达任何
vgdb --pid = 3145 lfra

请注意，在单独调用vgdb之后，Valgrind gdbserver会自动继续执行该程序。从GDB发送的监视命令不会导致程序继续：使用GDB命令（如“继续”或“下一个”）显式控制程序执行。

Valgrind的gdbserver info threads使用Valgrind特定的信息丰富了GDB 命令的输出。操作系统的线程号后跟Valgrind的该线程的内部索引（“tid”）和Valgrind调度程序线程状态：

（gdb）信息线程4 Thread 6239（tid 4 VgTs_Yielding）0x11f2832 in _ll_sysinfo_int80（）from /lib/ld-linux.so.2
* 3线程6238（tid 3 VgTs_Runnable）make_error（s = 0x8048b76“从伦敦调用”）在prog.c：202 Thread 6237（tid 2 VgTs_WaitSys）0x001f2832 in _ll_sysinfo_int80（）from /lib/ld-linux.so.21 prog 6234（tid 1 VgTs_Yielding）main（argc = 1，argv = 0xbedcc274）在prog.c：105
（GDB）

当给出选项--vgdb-shadow-registers=yes时，Valgrind gdbserver将允许GDB检查和/或修改Valgrind的影子寄存器。需要GDB 7.1或更高版本才能工作。对于x86和amd64，需要GDB版本7.2或更高版本。

对于每个CPU寄存器，Valgrind内核保留两个影子寄存器集。这些影子寄存器可以通过给出一个后缀s1 或s2分别为第一个和第二个影子寄存器从GDB访问。例如，eax可以使用以下命令检查x86寄存器 及其两个阴影：

（gdb）p $ eax
$ 1 = 0
（gdb）p $ eaxs1
$ 2 = 0
（gdb）p $ eaxs2
$ 3 = 0
（GDB）

浮动影子寄存器由GDB显示为无符号整数值，而不是浮点值，因为预期这些阴影值主要用于memcheck有效位。

Intel / amd64 AVX寄存器ymm0 也ymm15有它们的影子寄存器。然而，GDB使用两个“半”寄存器呈现阴影值。例如，半影子寄存器 ymm9是 xmm9s1（组1的下半部分），ymm9hs1（组1的 上半部分）， xmm9s2（组2的下半部分）， ymm9hs2（组2的上半部分）。请注意半登记名称的不一致表示法：下半部分以a开头x，上半部分以a开头，y 并且h在阴影后缀之前。

AVX影子寄存器的特殊表现是由于GDB独立地检索寄存器的下半部分和上半部分ymm。然而，GDB不知道阴影半记录必须被显示组合。

使用Valgrind gdbserver进行调试与本机调试非常相似。Valgrind的gdbserver实现是相当完整的，因此提供了大部分GDB调试功能。但是有一些限制和特点：

用法： vgdb [OPTION]... [[-c] COMMAND]...

vgdb（“Valgrind to GDB”）是一个小程序，用作Valgrind和GDB或shell之间的中介。因此，它有两种使用模式：

vgdb 接受以下选项：

本节介绍Valgrind监视器命令，无论选择了Valgrind工具，都可以使用。有关特定于工具的命令，请参阅Memcheck Monitor命令， Helgrind Monitor命令， Callgrind Monitor命令和 Massif Monitor命令。

监视器命令可以通过使用独立的vgdb或从GDB通过使用GDB的“监视器”命令（请参阅由Valgrind gdbserver监视命令处理）从shell命令行发送。客户端程序也可以使用VALGRIND_MONITOR_COMMAND客户端请求启动它们。

以下Valgrind监视器命令可用于调查Valgrind或其gdbserver在发生问题或错误时的行为。

3.3。功能包装

假设我们要包装一些功能

int foo（int x，int y）{return x + y; }

包装器是相同类型的函数，但是具有将其标识为包装的特殊名称foo。包装器需要包括支持宏valgrind.h。这是一个简单的包装器，它打印参数和返回值：

#include <stdio.h>
#include“valgrind.h”
int I_WRAP_SONAME_FNNAME_ZU（NONE，foo）（int x，int y）
{int结果;OrigFn fn;VALGRIND_GET_ORIG_FN（FN）;printf（“foo's wrapper：args％d％d \ n”，x，y）;CALL_FN_W_WW（result，fn，x，y）;printf（“foo's wrapper：result％d \ n”，result）;返回结果;
}

为了变得活跃，包装器只需要存在于与其包装的函数相同的进程'地址空间中的文本部分中，并且其ELF符号名称对于Valgrind可见。在实践中，这意味着要么编译到一个 .o和它连接，或编译的.so和 LD_PRELOAD在荷兰国际集团它。后者是更方便的，因为它不要求重新链接。

所有包装纸都有上述形式。有三个关键的宏：

I_WRAP_SONAME_FNNAME_ZU：这将生成包装器的真实名称。这是Valgrind读取符号表信息时注意到的编码名称。它说的是：我是一个命名的函数的包装器，foo它在ELF共享对象中找到一个空（“ NONE”）soname字段。规范机制是强大的，因为通配符可以用于声名和函数名。细节将在下面讨论。

VALGRIND_GET_ORIG_FN：一旦在包装器中，首先要抓住原始地址（以及需要的任何其他支持信息）。它存储在不透明类型的值中OrigFn。使用信息获取 VALGRIND_GET_ORIG_FN。在调用同一个线程中的任何其他包装函数之前，使这个宏调用非常重要。

CALL_FN_W_WW：最终我们想要调用被包装的函数。直接调用它不起作用，因为这只是让我们回到包装器并导致无限循环。相反，结果lvalue OrigFn和参数被交给一个形式的宏的家庭之一 CALL_FN_*。这些导致Valgrind调用原来的，并避免递归回包装。

这个方案具有独立的优点。可以以正常方式编译包装器的对象代码，并且不依赖外部脚本告诉Valgrind哪个包装器涉及哪些原件。

每个包装器都有一个名字，在最常见的情况下说：我是名称匹配FNPATT，其ELF“soname”匹配SOPATT的任何函数的包装器。FNPATT和SOPATT都可以包含通配符（星号）和其他通常不被视为有效的C标识符名称的字符（空格，点，@等）。

需要这种灵活性才能为POSIX pthread函数编写强大的包装器，通常我们不完全确定函数名称或soname，或者我们想要一次包装一整套函数。

例如，pthread_create 在GNU libpthread中通常是一个版本化的符号 - 一个名字以...结尾的符号 @GLIBC_2.3。因此，我们不确定它的真实姓名。我们也想覆盖任何形式的声纳libpthread.so*。所以包装的标题将是

int I_WRAP_SONAME_FNNAME_ZZ（libpthreadZdsoZd0，pthreadZucreateZAZa）（...正式...）{ ... 身体 ... }

为了将不寻常的字符写为有效的C函数名称，使用Z编码方案。名称是字面上的，除了一个首都Z作为转义字符，具有以下编码：

     Za编码*Zp +Zc：Zd。祖_Zh  - Zs（空格）ZA @ZZ ZZL（＃仅在valgrind 3.3.0及更高版本ZR）＃只在valgrind 3.3.0及更高版本

因此libpthreadZdsoZd0是的soname的编码libpthread.so.0 和pthreadZucreateZAZa是函数名的编码pthread_create@*。

宏I_WRAP_SONAME_FNNAME_ZZ 构造了一个包装器名称，其中soname（第一个组件）和函数名称（第二个组件）都是Z编码的。编码函数名称可能是令人厌烦的，并且通常是不必要的，因此I_WRAP_SONAME_FNNAME_ZU可以使用第二个宏 。该_ZU变体对于为C ++函数编写包装也是有用的，其中函数名通常使用一些其他约定在Z中发挥重要作用而被破坏。不得不第二次编码很快就会变得混乱。

由于函数名字段可能包含通配符，它​​可以是任何东西，包括只是*。soname也是如此。但是，一些ELF对象（特别是主要的可执行文件）没有声名。任何缺少soname的对象都被视为它的soname NONE，这就是为什么上面的原始例子有一个名字 I_WRAP_SONAME_FNNAME_ZU(NONE,foo)。

请注意，ELF对象的soname与其文件名不同，尽管它通常是相似的。您可以libfoo.so使用该命令 找到对象的soname readelf -a libfoo.so | grep soname。

包装器替代无限功能系列的能力是强大的，但是在ELF对象出现和消失的情况下（dlopen'd和dlclose'd）在飞行中会带来复杂性。Valgrind试图在这种情况下保持明智的行为。

例如，假设一个进程已经削减（带有soname的ELF对象）object1.so，其中包含 function1。它function1立即开始使用 。

过了一会儿，它变得浑浊wrappers.so，里面包含一个包装function1（soname） object1.so。所有后续调用 function1都将重新路由到包装器。

如果wrappers.so是以后dlclose'd，呼叫function1自然地路由到原来的。

或者，如果object1.so 是dlclose'd但wrappers.so仍然保留，则导出的包装器将wrappers.so 变为不活动的，因为无法获取 - 没有原始文件可以再调用。然而，Valgrind记得包装仍然存在。如果 object1.so最终再次出现，包装将再次活跃。

简而言之，valgrind会检查所有代码加载/卸载事件，以确保当前活动的包装器集合保持一致。

第二个可能的问题是冲突的包装器。很容易加载两个或更多的包装纸，这两个包装纸都称为包装纸，用于第三个功能。在这种情况下，Valgrind会在第二次出现时抱怨有冲突的包装者，并且只会荣获第一名。

弄清楚发生了什么事情，因为包装的动态性质可能很困难。该 --trace-redir=yes选项可以通过在每个mmap/ munmap 事件影响代码（文本）后显示重定向子系统的完整状态 。

有两个中心概念：

包装和重定向子系统的状态包括一组规范和一组主动绑定。通过观看 代码（文本）部分的所有mmap/ munmap事件来获取/丢弃规格 。从规范中重新计算主动绑定集，以及对规范集进行任何更改后，所有已知的符号名称。

--trace-redir=yes 在任何此类事件之后显示两个集合的内容。

-v 每次首次使用活动规范时，都会打印一行文本。

因此，为了最大化调试效率，您将需要使用这两个选项。

一个最后的评论。功能包装设备与Valgrind的替换（重定向）指定功能的能力密切相关，例如将调用重定向 malloc到其自身的实现。实际上，替换功能可以被认为是不称为原始的包装功能。然而，为了使实现更加健壮，两种截取（包装与替换）的处理方式不同。

--trace-redir=yes显示替换和包装功能的规范和绑定。为了区分两者，使用打印R->包装打印替换绑定 W->。

在大多数情况下，函数包装实现是强大的。唯一重要的注意事项是：在包装器中，在调用任何其他包装功能之前，请OrigFn使用该信息 VALGRIND_GET_ORIG_FN。一旦你有了 OrigFn，任意调用之间的递归和longjumps之间的包装应该正常工作。包装函数之间从来没有任何交互，只是替换函数（例如malloc），所以你可以malloc从包装器中安全地调用 etc。

上述评论对于{x86，amd64，ppc32，arm，mips32，s390} -linux是正确的。由于ppc64-linux ABI（可能设计不佳）ppc64-linux功能的包装更加脆弱。这要求使用一个影子堆栈来跟踪包装和替换功能的条目/出口。这给出了两个限制：首先，包装器的长时间跳过会迅速导致灾难，因为阴影堆栈将无法正确清除。其次，由于阴影栈具有有限的大小，因此包装/替换功能之间的递归仅可能达到有限的深度，Valgrind不得不中止运行。这个深度目前是16个电话。

对于所有平台（{x86，amd64，ppc32，ppc64，arm，mips32，s390} -linux），所有上述注释都适用于每个线程。换句话说，包装是线程安全的：每个线程必须单独遵守上述限制，但不需要进行任何类型的跨线程合作。

如上面的例子所示，要调用原来你必须使用宏的形式CALL_FN_*。由于技术原因，无法创建单个宏来处理所有参数类型和数字，因此提供了覆盖最常见情况的一系列宏。在下文中，'W'表示机器字型的值（指针或C long），'v'表示C的void类型。目前可用的宏是：

CALL_FN_v_v  - 调用类型为void fn（void）的原始文件
CALL_FN_W_v  - 调用long fn（void）类型的原始文件CALL_FN_v_W  - 调用类型为void fn（long）的原始文件
CALL_FN_W_W  - 调用long fn（long）类型的原始文件CALL_FN_v_WW  - 调用类型为void fn（long，long）的原始文件
CALL_FN_W_WW  - 调用long fn（long，long）类型的原始文件CALL_FN_v_WWW  - 调用类型为void fn（long，long，long）的原始文件
CALL_FN_W_WWW  - 调用long fn（long，long，long）CALL_FN_W_WWWW  - 调用long fn（long，long，long，long）类型的原始文件
CALL_FN_W_5W  - 调用long fn（long，long，long，long，long）
CALL_FN_W_6W  - 调用long fn（long，long，long，long，long，long）
等等，直到
CALL_FN_W_12W

可以根据需要扩展支持的类型集。令人遗憾的是，这种限制存在。功能包装已被证明难以实施，具有一定显然不可避免的水平。经过几次实施尝试，目前的安排似乎是最不利的权衡。至少它在动态链接和动态代码加载/卸载的情况下可靠地工作。

您不应尝试用不同类型签名的包装器包装一个类型签名的功能。这样的诡计一定会导致崩溃或奇怪的行为。这不是函数包装实现的限制，只是反映了如果你不小心，它给你扫射的力量来射击自己。想象一下，您可以通过编写一个与任何soname中的任何函数名称相匹配的包装器，实际上就是一个声称是进程中所有函数的包装器的破坏。

在源代码树中， memcheck/tests/wrap[1-8].c提供了一系列的例子，从很简单到相当先进。

mpi/libmpiwrap.c是一个包装大而复杂的API（MPI-2接口）的例子。这个文件定义了近300个不同的包装器。