来自文档里的 Extension介绍：http://dynamorio.org/docs/page_ext.html
drvector、hashtable、drtable开头，属于 Container Data Structures （容器数据结构）
drutil 开头， 属于 Instrumentation Utilities （实用工具）
drcovlib 和 drmodtrack 开头， 属于Code Coverage Library （代码覆盖率库）
drsym 开头， 属于Symbol Access Library （符号访问库）
drreg_
以 drreg 开头，属于Register Usage Coordinator（寄存器使用协调器）
drreg DynamoRIO寄存器管理扩展是在多个仪器组件之间选择，保留和使用寄存器的中介。该界面旨在与drmgr仪器通过方案一起使用。当在drmgr仪器插入阶段使用时，结果最有效。在插入阶段之外使用，例如在drmgr的仪器到仪器转换阶段，或完全在drmgr之外使用，但是可能无法优化重复的溢出和恢复
drreg API基于预留模型（注意这里的预留模型）。每个通用寄存器可以预留或者说申请使用一段时间然后 释放。如有必要，预留 过程会溢出 寄存器里属于原应用程序的值（因为我们要用寄存器来存放新值，这里说的溢出，我觉得是另外保留）。预留意味着对该寄存器的独占访问权。预留可以扩展到 跨应用程序指令，在这种情况下，当 中间的应用程序指令读取或写入该寄存器时，drreg将自动恢复 或重新溢出 属于应用程序的值（这里的溢出就是更新我们保存的原寄存器值），同时仍然保留客户端在该寄存器中的值以便在应用程序指令之后使用。预留 应该不会延伸到基本块的末尾。这里 寄存器存放了两种值，一种是 属于原应用程序的，一种是属于 客户端的。
drreg 假设只有应用程序指令（非元指令） 需要读取 应用程序值（即原来寄存器里保存的属于应用程序的值）。drreg 假设： 对于一个不再 预留的寄存器，尽可能的等待 去恢复那个溢出值 是安全的。也就是说，如果一个寄存器 我们客户端不再需要了，我们也不会急着去 恢复那个溢出值，而是等待直到有应用程序指令去读取这个寄存器（应该是这样的，懒惰恢复策略，而且对于应用程序指令好像会自动调用drreg_get_app_value 去恢复溢出寄存器）。如果一个客户端插入了 instrumentation 去读取 那个应用程序值，或者 使用的一个库里的例程会去读取，那么客户端就需要告诉 drreg 去 恢复那个需要的 溢出值，恢复可以用过 drreg_restore_app_values(） 或者 drreg_get_app_value() 来实现。这种情况就像是 懒惰恢复 的障碍。库例程里出现这种障碍的还包括 所有的 读取应用程序指令操作数 的操作，包括： dr_insert_mbr_instrumentation(), dr_insert_call_instrumentation() 等等。除此之外，还包括当TLS 申请的不够时 的 dr_insert_clean_call()，因为此时 作为结果是， drreg 和 DR 共享插槽。
drwap开头， 属于Function Wrapping and Replacing （函数封装与替换）
drx_
以drx 开头， 属于DynamoRIO eXtension utilities （DynamoRIO 性能扩展）
drx 扩展提供了多种检测函数，并且使用BSD 开源协议，虽然 drutil 扩展也包含一些 检测工具，但是使用的是 LGPL 2.1 开源协议。
多进程应用程序的常见方案是父进程直接终止子进程。这对于大多数动态工具来说都是有问题的，因为这使得每个子进程都没有机会输出其检测结果。在Windows上，drx提供了一个名为“软杀死”的功能来解决这种情况。启用后，此功能将监视终止子进程的系统调用，无论是直接的还是通过作业对象。检测到后，它会通知客户端，然后客户端会通过微调(nudge)通知目标进程。通常，这个微调将执行检测输出，然后终止其进程，允许父进程简单地跳过自己的终止请求。 nudge处理程序通常应该处理多个请求，因为父级通过多种机制杀死每个子进程并不罕见。
drx库还演示了一个简约缓冲API。它的API目前正在调整。这些缓冲区可能包含在检测期间收集的数据痕迹，例如存储器跟踪，指令跟踪等。注意，每个线程缓冲区用于所有的实现。目前存在三种类型的缓冲区。
Trace Buffer
Circular Buffer
Fast Circular Buffer
drmgr_
以drmgr 开头， 属于Multi-Instrumentation Manager （多仪器管理）
drmgr DynamoRIO扩展提供了一个中介，用于组合和协调多个 instrumentation 通过。它将某些DynamoRIO事件和API例程替换为自己的版本，这些版本在多个组件之间进行调解，通常是几个库和一个客户端，尽管它对于将客户端拆分为模块也很有用。 drmgr有助于开发可以组合的仪器框架和库
Event Replacement
为了提供对事件回调的排序控制，drmgr取代了许多DynamoRIO的事件。对于其中许多，只需用drmgr_替换dr_就足够了，因为它将使用默认优先级。要请求优先级，请使用drmgr_register_例程的_ex版本。基本块事件是一种特殊情况，因为它完全被一组新的多个事件替换，用于检测的不同阶段。
Instrumentation Stages
drmgr将代码更改分为三种类型：
- 应用程序到应用程序转换：应用程序代码本身的更改，旨在影响应用程序行为或应用程序性能
- 检测插入：在应用程序指令之间添加监视代码
- Instrumentation-to-instrumentation转换：通常，优化应用于整套插入的检测
检测插入分为两部分：分析完整的应用程序代码（在从其原始形式进行任何更改之后），然后插入检测，一次一条指令。结果是四个独立的连续阶段：
- 应用程序到应用程序的转换
- 应用代码分析
- 检测插入，一次一个指令
- 检测到检测 的转换
注册drmgr的每个组件都可以注册四个阶段中的部分或全部。在每个阶段，调用每个注册的组件的回调。它将不同类型的更改组合在一起，并允许它们假定以后的更改不会使其分析或操作无效。检测插入在一个正向传递中执行：对于每个指令，调用每个注册的组件。这简化了寄存器分配（寄存器分配由单独的Extension drreg提供）
Auto Predication
默认情况下，drmgr启用自动预测，该预测使用 ARM 上当前指令的谓词来预测所有指令。客户端可以通过在插入bb事件开始时调用drmgr_disable_auto_predication（）来选择退出。