來自文檔裏的 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（）來選擇退出。