基于QEMU的動態二進制插樁技術

鄒 偉 高 峰 顏運強

(中國工程物理研究院計算機應用研究所 四川綿陽 621999)

近年來，嵌入式軟件的規模與復雜度愈發增加，如何進一步通過軟件測試、分析與驗證提高其可靠性，一直是學術界關注的焦點.其中，軟件插樁是一項十分重要的應用于該領域的動態分析技術.通過軟件插樁技術[1-2]可有效收集程序執行過程信息，如路徑覆蓋信息、函數調用關系信息，能用于軟件性能分析、程序優化、測試覆蓋分析、測試用例生成與約簡、軟件缺陷檢測與修復.

當前，軟件插樁技術包含源代碼級[3]和二進制級[4-6]2種插樁方式，其中二進制插樁技術又分為動態方式和靜態方式.研究表明[7]：源代碼級插樁技術對軟件具有很強的侵入性，無法應用于逆向工程或軟件測試；在二進制插樁技術方面，靜態二進制插樁技術，由于其較強的侵入性和代碼數據難以區分等難題，在實際工程中極少使用；和靜態二進制插樁不同的是，動態二進制插樁[1-2,7](dynamic binary instrumentation)技術通過接管目標程序控制流，為目標程序提供虛擬運行環境，進而監視收集目標程序運行信息.因而，動態二進制插樁技術既不需要重新編譯生成目標碼，又不會改變目標碼的執行流程，完全不影響原程序執行邏輯，具有很好的實用性.目前，動態二進制插樁工具主要包含Pin[8-9]，Valgrind[10]，DynamoRIO[11]等，這些工具都在動態二進制翻譯的過程中對軟件插樁，可以完成內存使用、調用流、覆蓋信息等程序運行信息分析.然而，這些工具還有十分顯著的缺陷，即它們只能對用戶級程序進行插樁分析，不能完成對系統級程序分析，難以滿足嵌入式系統軟件動態分析需要.

因此，亟需能分析嵌入式全系統軟件二進制目標碼的工具.于是，本文預想通過修改動態二進制翻譯技術的全系統仿真工具使其具有動態二進制插樁功能，進而解決上述問題.現在，基于動態二進制翻譯技術的系統級仿真工具主要包括QEMU(quick emulator)，Bochs,VirtualBox,VMware，其中僅QEMU支持除X86以外其他體系結構的目標機和宿主機，適合用于嵌入式系統.QEMU[12]利用可重定位的動態二進制翻譯技術，在多種體系結構的宿主機下高效全系統仿真多種目標機體系結構(X86,ARM,MIPS,PPC)，包括操作系統及其所有應用軟件都可以無修改的通過QEMU加載仿真運行.這是因為，QEMU在動態翻譯執行目標系統程序過程中，模擬了包括CPU、RAM、中斷控制器以及其他外設在內的目標體系結構的全部硬件.翻譯執行過程中，如果在QEMU仿真執行序列中插入保存模擬運行環境快照的探針功能，那么將為程序的動態分析提供寶貴的運行信息.

本文的主要貢獻有3個方面:

1) 研究QEMU的動態二進制翻譯全系統仿真執行過程，提出完成中間碼層次上的二進制基本塊插樁，跟蹤和記錄程序執行流;

2) 分析與實驗研究插樁對仿真性能的影響，發現日志輸出是影響仿真性能的關鍵因素，通過分析計算，解決了由插樁引起的仿真性能驟降的不良影響;

3) 設計插樁日志分析工具，完成了對嵌入式全系統的執行流跟蹤、函數調用圖、覆蓋率分析.

1 相關工作

通過文獻查閱發現，目前已有一些學者研究使用和改進QEMU來進行軟件動態分析.文獻[13]對程序執行路徑跟蹤，查找程序執行熱路徑.該文獻通過在QEMU的基本塊首部插入熱路徑預測和跟蹤指令，并在單獨的線程中對熱路徑進行分析，完成了熱路徑記錄任務，但由于對熱路徑進行在線解算，嚴重影響了仿真性能.文獻[14]改進QEMU的動態二進制翻譯和GDB(GNU project debugger)調試樁，來支持通過GDB控制Linux進程動態插樁，以達到跟蹤Linux進程目的；文獻[15]在QEMU翻譯過程中標記函數調用和返回指令，獲取Linux進程的函數調用關系圖；文獻[16]對每一條翻譯后的目標機指令增加dump state指令來收集進程的執行信息，并發送到獨立進程進行輸出，顯著提高了統計運行信息速度；文獻[17]對Call/Ret指令的追蹤，完成軟件運行時的函數剖面分析，成功應對了函數執行過程被硬件中斷干擾的情況，保證了函數時間剖面分析的準確性,但該文獻對程序追蹤粒度太粗，不能用于程序流圖、語句覆蓋信息產生；文獻[18]提出一種故障注入方法來模擬系統故障、檢驗軟件的故障容忍性；文獻[19]在中間碼的層次上提出了一系列鉤子指令，獲取目標系統的運行信息，然而其需要為每一種宿主機翻譯鉤子指令，靈活度低.

從上面這些文獻可以看出：1)目前基于QEMU的動態二進制軟件分析尚未形成統一的理論和方法，研究者在插樁點選擇和探測內容上各不相同.2)研究者都側重于使用和改進QEMU進行用戶級程序執行信息收集.因此，本文旨在通過對動態二進制插樁技術的分析，結合QEMU使用基本翻譯塊的事實，借鑒Gcov[20]的覆蓋分析方法，在基本塊粒度上插樁，深度修改QEMU，實現二進制插樁功能，并在此基礎上形成對基本塊執行日志分析的工具，解決了嵌入式全系統軟件的動態二進制分析問題.另外，本文還做了更進一步的工作：1)減少QEMU仿真運行日志記錄內容，將日志在線分析變為事后分析，提升仿真性能；2)本文通過解決直接塊鏈不返回問題，將記錄日志信息精細到基本翻譯塊的層次，因而可以同時完成熱路徑分析、函數剖面分析、函數調用流分析、中斷流分析等，豐富了動態二進制插樁在程序動態分析的應用范圍.

2 動態二進制插樁與QEMU

本節簡要介紹動態二進制插樁和QEMU的技術原理，幫助說明后文對QEMU插樁改進.

2.1 動態二進制插樁

動態二進制插樁，就是在執行客戶機程序的流程中，通過添加、修改和刪除機器碼等操作[5]，支持監控客戶機軟件的一種程序仿真運行技術.在二進制插樁領域，通常以基本塊(basic block)為單位進行插樁，完成基本塊運行信息收集，生成程序分支(arc)和程序流圖，分析程序動態運行信息.所謂基本塊，就是程序運行中最基本的指令序列.在這個指令序列中，所有指令順序執行.停止語句和轉向語句只能是基本塊的最后1個語句.分支(arc)是指基本塊之間的控制流,它連接程序中所有有效基本塊形成程序流圖.分支表示基本塊之間的結構關系，通過分支可以知道程序在執行完基本塊的所有語句后會轉移到哪一個基本塊繼續執行.程序流圖是程序結構的圖形表示.基本塊是流圖中的節點，程序的所有基本塊組成了程序流圖的節點集，程序第1個語句所在的基本塊稱為首節點.把基本塊之間的控制流向作為節點之間的有向邊集合.對程序流圖來說，節點就是基本塊，代表了程序的執行語句；有向邊就是分支，代表了程序的控制流；首節點就是程序的起始點.

依據插樁技術不同，基本塊插樁可以在編譯時進行，也可以在運行時進行.例如GNU(GNU’s not Unix)的覆蓋率統計工具Gcov就是通過編譯選項在基本塊上進行二進制插樁，以實現對軟件的覆蓋統計.當插樁后的程序運行時，動態填充程序內的基本塊、分支和程序流圖.當程序運行結束時，將基本塊、分支和程序流圖輸出到文件中，最終由Gcov完成動態分析.而Pin，Valgrind，DynamoRIO等工具則是通過動態二進制翻譯技術完全控制目標二進制程序的執行.它們在運行目標二進制程序時進行二進制翻譯，發現目標程序中的基本塊并進行插樁，最后在程序結束時給出程序運行動態信息.目前這些工具存在較大的局限性，例如它們都只能完成應用級程序的動態分析，還沒有一種工具可以完成系統級動態二進制插樁，由此可見，系統級程序的動態二進制分析對二進制插樁技術來說是一個巨大的挑戰.

2.2 QEMU

QEMU可進行應用級軟件仿真和系統級軟件仿真.進行系統級軟件仿真時，QEMU提供包括處理器、存儲器、總線以及中斷控制器、MMU(memory management unit)、FPU(float point unit)以及其他外設的全系統仿真，可以不作修改運行任何客戶機系統軟件.QEMU[12-13]主要包含2方面任務：1)執行調度；2)動態二進制翻譯.仿真執行時，QEMU判斷當前PC(program counter)對應基本翻譯塊(translate block, TB)是否已經在TB Cache中，如果不在TB Cache中，則進行動態二進制翻譯；否則，執行該基本翻譯塊的宿主機指令.當執行到未翻譯的客戶機指令序列時，則表明當前PC對應基本塊的開始，QEMU產生基本翻譯塊，開始進行動態二進制翻譯.動態二進制翻譯包含翻譯前端和翻譯后端2個階段，完成客戶機指令序列到宿主機指令序列的語義等效轉換.第1階段，函數gen_intermediate_code讀取客戶機指令序列進行反匯編產生中間碼(intermediate code).在一些學者的研究中，中間碼或稱為中間表示，或稱為虛擬指令集.在這1階段，跳轉指令確定了基本翻譯塊的邊界.第2階段，函數tcg_gen_code遍歷中間碼，將中間碼轉換成宿主機指令，保存翻譯塊并加入TB Cache.

3 QEMU插樁改進

QEMU的動態翻譯仿真執行流程,與Pin，Valgrind，DynamoRIO等工具的動態插樁過程十分類似.然而，Pin，Valgrind，DynamoRIO等不支持系統級程序的仿真執行[2]，也不支持交叉動態二進制翻譯.所謂交叉動態二進制翻譯，即原二進制程序同翻譯后的二進制程序體系結構不同.PinOS是一個通過Pin開發的全系統的插樁工具，但其僅能用于Linux架構[2]，不支持嵌入式系統.而QEMU全系統仿真時完全掌握系統運行流程和仿真環境狀態.因此，可以對其進行深度修改，使其具有二進制插樁功能，解決嵌入式全系統的軟件動態分析的難題.而要使QEMU具有二進制插樁功能，必須解決3個問題：

1) 流程嵌入，即如何將插樁過程附加到QEMU仿真執行過程;

2) 樁點選擇，即在基本塊中如何選擇決策探針插入位置;

3) 探針內容，即在探針中如何收集以及收集哪些客戶機信息來滿足插樁日志分析工具設計.

3.1 流程嵌入

當前，一些文獻通過QEMU客戶機程序執行流程分析，將探針插在執行調度循環中，如圖1所示:

Fig. 1 Instrumentation in the main cycle圖1 主循環內插樁

在執行基本塊前后分別插入探針，獲取虛擬CPU運行信息，記錄PC和時間戳.但這種方法會丟失一些基本塊運行信息.這是因為QEMU使用了直接塊鏈技術.使用直接塊鏈技術[12-13]后，執行調度程序一旦進入執行基本塊流程，控制流不返回執行調度主循環，而直接選擇下一個基本塊繼續執行.如圖1所示，開始執行基本塊后，控制流進入包含多個基本塊的程序流圖，不能立即返回執行調度主循環，從而導致丟失部分程序運行信息.為解決這一問題，一些文獻提出取消直接塊鏈功能[13,15]，甚至提出采用單步執行的方式[13].這些方法雖可解決上述問題，卻嚴重制約QEMU仿真性能.

針對這一問題，要收集基本塊執行信息，只能將探針嵌入基本塊執行過程內部，如圖2所示.在基本翻譯塊的前后分別插入探針.這樣，即使采用直接塊鏈技術，也不會丟失程序運行信息.基本塊運行時，記錄基本塊開始PC和時間戳.基本塊結束時，記錄其結束時間戳和控制流轉移目的地址.

Fig. 2 Instrumentation in basic block圖2 基本塊內插樁

Fig. 3 The flow of dynamic instrumentation in basic block圖3 基本塊動態插樁流程嵌入示意圖

然而，基本塊內嵌入探針并不是簡單的工作.例如，探針插入可以在翻譯前端完成也可以在翻譯后端完成.本文選擇在翻譯前端完成，即在函數gen_intermediate_code中完成.這是因為：1)該方法可以適合多種宿主機，不需要為每種宿主機體系結構修改代碼;2)在翻譯前端可以更方便通過代碼操作客戶機運行環境狀態信息,而在翻譯后端QEMU所能使用的信息僅僅是中間碼，完全沒有客戶機環境信息.因此，本文的動態插樁過程如圖3所示.在每一個基本塊產生中間碼之前，函數gen_intermediate_code先進行塊首插樁，插入探針，將探針中間碼添加在基本塊中間碼首部.遇上跳轉指令離開基本塊時，函數gen_intermediate_code進行塊末插樁，插入探針，將探針中間碼添加在基本塊中間碼末端.后端翻譯時，即函數tcg_gen_code中，探針中間碼連同基本塊功能中間碼一起翻譯成宿主機指令序列，從而完成了對插樁流程的嵌入.

3.2 樁點選擇

Fig. 4 Intermediate code and instrumentation selection圖4 中間碼與樁點選擇示意圖

問題轉化為研究基本塊前端翻譯過程，即如何確定基本塊中的插樁點.插樁點的選擇既要保證覆蓋基本塊所有執行路徑，又不會產生冗余記錄.根據研究發現，基本塊中間碼組織結構如圖4所示，除客戶機基本塊翻譯來的中間碼外，中間碼中還包括了用于控制直接塊鏈退出的其他中間碼，如ld,brne,goto_tb,exit_tb等虛擬指令.仿真執行時，控制流有3條路徑離開基本翻譯塊.

1) 客戶機軟件控制流從位置a進入基本翻譯塊，將tcg_exit_req加載到變量flag后，控制流判斷flag是否為0，如果不是，跳轉到最后1條指令exit_req_lable處，從出口c離開，返回執行調度主循環.這表示被仿真系統處理器收到外設產生中斷或產生了異常等，需退出直接塊鏈執行.

2) 客戶機軟件控制流從位置a進入基本翻譯塊，將tcg_exit_req加載到變量flag后，控制流判斷flag=0時，控制流執行完其他中間指令，遇見指令goto_tb，從出口b離開，進入直接塊鏈控制流.

3) 客戶機軟件控制流從位置a進入基本翻譯塊，將tcg_exit_req加載到變量flag后，控制流判斷flag=0時，控制流執行完其他中間指令，控制流執行完其他中間指令后，未遇見指令goto_tb，從出口c離開，返回執行調度主循環.

顯然，為覆蓋全部路徑，應選擇圖4中所示3處插樁點(三角形).這是因為，在直接塊鏈的控制流中，當執行一個基本塊時，首先會檢查是否需要退出直接塊鏈執行.如果檢查到需要退出執行，則控制流直接轉到當前塊末端，而導致當前基本塊的客戶機指令沒有執行.如果插樁不當，會將此種未運行客戶機指令的情況虛假統計到日志記錄中.

另外，除以上3條路徑離開基本塊以外，QEMU還可以在異常或中斷觸發下離開基本塊.為簡化插樁操作，本文未對此種路徑進行插樁.這是因為，異常或中斷產生對嵌入式系統來說是隨機的，我們可以認為這是疊加在所有的基本塊運行信息上的白噪聲信號，不會影響最終分析工具的結果.

3.3 探針內容

插樁流程和探針點選擇決策后，確定探測內容和分析時機成為首要問題.理論上，動態二進制插樁可以探測記錄目標體系結構全部信息，包括全部寄存器值、存儲器內容、程序棧和堆的值、程序執行流以及進入退出基本塊時間等.但為了減少系統壓力，盡量不影響系統仿真速度，在實踐中僅記錄少量體系結構運行信息.例如Gcov只記錄了基本塊的執行次數和基本塊的進入地址，因而其函數剖面分析功能結果存在誤差.本文參照Gcov，將探測內容定義成四元組(type,ts,pc,dest).type表示插樁點的位置，依據插樁點位置的選擇，type分別可以取1,2,3這3種值；ts表示探針運行時刻客戶機時間戳；pc表示插樁點運行時客戶機的PC值；dest僅在type=2時有效，表示下一個基本塊的首地址，記錄程序中的跳轉信息.

圖5是本文所述插樁方法產生的動態插樁實例.目標二進制基本塊取自EEMBC(Embedded Microprocessor Benchmark Consortium)組織Core Mark1.0中的main函數.該基本塊包含2條指令，分別位于0x159a和0x159c.

從圖5可以看出，此時處理器工作在Thumb模式.經過前端翻譯后轉換成中間碼，共產生12條指令.經3處插樁9條指令后，共計21條指令.這3處插樁分別調用helper函數profile_enter_tb，profile_set_pc_tb，profile_exit_tb實現對執行路徑及時間戳的記錄.

3.4 性能優化

根據3.3節分析，每個插樁點都需要記錄客戶機時間戳.記錄時間戳最簡單的方法就是通過系統調用獲取宿主機當前tick作為四元組中的ts.然而，采用這種方法存在2方面的問題:1)每一個基本塊獲取一次tick，即陷入系統一次，嚴重影響動態二進制翻譯執行效率；2)宿主機系統的時間流逝包含了執行調度、動態二進制翻譯等非客戶機指令運行時間，造成客戶機執行時間打點偏移.本文提出的解決方案是，在動態二進制翻譯執行過程中，將流逝時間解釋為指令計數.因為對于確定的計算機系統來說，單條指令的執行通常在一定的時間內完成.因此，可以通過指令計數來反映客戶機系統時間.

指令計數可以在仿真運行中統計，但這不是最佳方法.在插樁日志處理工具的設計中，本文將日志記錄轉化為基本塊序列.在執行基本塊中，控制流順序執行，因此可以通過執行基本塊的開始地址和結束地址計算指令計數，從而反映基本塊執行時間.這樣插樁內容可定義為三元組(type,pc,dest)，不包含時間戳，而采用事后分析基本塊指令計數來得到基本塊執行時間.這樣就減少系統調用陷入，也減少了日志輸出量，從而限制插樁程序對仿真性能的影響(見5.1節).

本文通過性能測試顯示，日志輸出I/O嚴重影響了仿真性能(見5.1節).為了減少日志輸出，本文在第4節分析工具設計過程中進一步研究發現，可以將每次基本塊運行日志記錄優化為一條，這樣就可以把日志輸出減少到一半.這是因為，當把計時方式改為指令計數時，探針不再需要記錄基本塊運行開始時間.因此，只需在離開基本塊控制流插入探針，就能計算出該基本塊對應的函數和語句執行時間.如果控制流跳轉到其他基本塊，離開基本塊時還應該記錄目標基本塊地址，用于函數調用關系計算.通過這樣的方式，本文減少了插樁對仿真性能的不良影響.為減少在線分析對仿真性能的影響，同Gcov一樣，本文采用事后分析日志的策略.

4 分析工具

為分析插樁代碼運行日志記錄，本文設計開發插樁日志分析工具(instrumentation analysis tool, IAT)，其工作原理如圖6所示.步驟1，讀取運行日志記錄，完成基本塊還原；步驟2，讀取目標二進制可執行文件調試信息，還原地址與源代碼的映射關系；步驟3，計算基本塊命中源代碼情況，從而解算出函數調用關系、覆蓋信息等.

Fig. 6 IAT schematic diagram圖6 IAT原理圖

4.1 基本塊還原

當插樁完成后，QEMU仿真運行客戶機二進制代碼產生記錄日志文件.日志文件中每行包含前文所述的三元組(type,pc,dest)探測內容.如圖6右側①所示，IAT對記錄日志逐行掃描，獲取每一個基本塊的地址范圍、目標基本塊等信息.然而，這些信息僅含程序運行覆蓋的基本塊、分支和程序流.如果要進一步統計軟件函數調用流圖、基本塊覆蓋情況、語句覆蓋情況、函數覆蓋情況甚至分支覆蓋情況，必須獲取目標機軟件的全部基本塊、語句、函數與二進制目標碼的映射關系.

4.2 源碼信息還原

在僅有二進制的情況下，可以使用調試信息來獲取這種映射關系.現代編譯器在將高級語言轉換成機器碼，同時在目標二進制文件中裝入調試信息，方便程序調試和和軟件優化.通常，調試信息按DWARF[21]格式保存在目標二進制文件的調試信息段.根據DWARF信息，調試器能獲取地址和符號的對應關系、地址和編譯單元的對應關系、能獲取變量類型、變量存儲位置等信息.然而，為了適應多種編譯器和目標體系結構，DWARF格式十分復雜.本文借助軟件包elftools來分析DWARF格式.通過elftools提供的API，IAT讀取目標二進制可執行文件，獲取其中全部函數及其地址范圍、全部編譯基本塊及其地址范圍等.如圖6左側②所示，IAT通過調試信息項sub_program獲取所有函數的地址范圍，形成以(function,address)為關鍵字的函數集合.IAT通過調試信息項line_program獲取編譯單元，并通過所有函數過濾出可執行編譯單元，形成以(file,line,column)為關鍵字的運行單元集合.這樣，就可以通過分析函數集合和運行單元集合的命中性和執行時間來完成軟件分析.

4.3 覆蓋標記與調用計算

在基本塊和源碼信息還原后，IAT逐一遍歷基本塊完成軟件分析.在本文中，軟件分析指對軟件call graph,function profile,coverage,control flow等信息分析.對于每一個基本塊，如果該基本塊地址范圍(start_PC，end_PC)命中函數集中某(function，address)的地址范圍，則增加該函數運行時間，并標記函數已覆蓋；如果該基本塊地址范圍(start_PC，end_PC)命中運行單元集合中的某(file，line，column)運行單元，則標記該(file，line，column)運行單元已覆蓋.如果該基本塊包含dest_PC，那么標記該控制流轉移過程和函數調用關系.

對全系統仿真來說，在進行控制流和函數調用關系解算時還需要考慮系統中斷的影響.這是因為一些時候主控制流會被中斷控制流打斷，中斷控制流會被計入主控制流或者中斷函數被計為被打斷函數的子函數.這樣，一方面IAT必須將中斷控制流從主控制流中剪去；另一方面，IAT必須記錄被中斷打斷的主控制流，以便中斷控制流退出后將控制流接續到被打斷的主控制流.被中斷所打斷的中斷控制流可以采用相同的方法解決.

5 插樁實驗與程序運行結果

本文采用EEMBC組織提供的嵌入式性能評估套件CoreMark1.0[22]完成插樁性能測試和插樁結果分析. CoreMark程序測試集包含鏈表、矩陣、狀態機等相關操作的性能測試用例.

5.1 性能測試與優化

插樁后，當程序執行探針時，QEMU將目標機程序運行時信息輸出到指定文件.本文在2個數量級上運行CoreMark，即分別插樁運行CoreMark 10～150次和執行CoreMark 10 000～150 000次，計算插樁代價.這是因為，日志輸出I/O嚴重影響了仿真性能.如圖7～8所示.在圖7中，淺色(藍色)(T)數據系列表示原QEMU運行CoreMark的結果為1 690 iter/s；深色(橙色)(NIOST)數據系列表示插樁但不進行日志輸出的修改，其運行CoreMark的結果為1 324 iter/s，性能下降21%.然而，插樁并進行I/O的修改最快僅為0.21 iter/s，性能下降99.987%，如圖8所示.這表明插樁本身對仿真性能的影響遠小于I/O對仿真性能的影響，為本文第3節的性能優化提供了依據.因此，本文做了大量的工作來減少插樁過程中I/O對仿真性能的影響，如3.4節所述.通過優化，仿真性能得到顯著提高，如圖8所示.圖8中，最淺色(藍色)(GT)數據系列表示包含獲取時間的QEMU修改，其仿真運行CoreMark的結果為0.08 iter/s；最深色(橙色)(NT)數據系列表示不包含獲取時間的QEMU修改，其仿真運行CoreMark的結果為0.13 iter/s，與GT相比性能提高1.70倍；較深色(綠色)(NST)數據系列表示不獲取時間，每個基本塊僅有一個插樁點的QEMU修改，其仿真運行CoreMark的結果為0.21 iter/s，與NST相比性能提高1.57倍，性能累計提高2.68倍.

Fig. 7 Instrumentation without I/O圖7 插樁不進行I/O

Fig. 8 Instrumentation with I/O圖8 插樁進行I/O

然而，這仍然遠不能滿足實際需要，還需提高仿真性能.為進一步減少插樁對仿真性能的不良影響，本文通過實驗研究分析，發現對日志進行分批集中輸出，而不是產生1條就輸出1條，即不是在每一個樁點都進行輸出，僅在日志達到指定的緩沖區大小后進行日志集中輸出寫入文件，可以有效地提高插樁后程序的仿真執行效率，如圖9所示.圖9中淺色(藍色)(B1K)數據系列表示將跟蹤日志輸出緩沖設置為1 KB時，其仿真運行CoreMark的結果為64.41 iter/s；深色(橙色)(BKK)數據系列表示將跟蹤日志輸出緩沖設置為1 MB時，其仿真運行CoreMark的結果為64.61 iter/s，與B1K相比速度提高0.003倍.由此可見，緩沖大小對仿真速度并沒有顯著提高，然而采用集中輸出日志的方法比在每個樁點中都進行日志輸出，仿真性能提高26.24倍，同不進行優化相比，仿真性能提高303.43倍.因此，本文最終選擇采用優化后的集中輸出方案，仿真運行CoreMark的結果為64.41 iter/s.

Fig. 9 Instrumentation with buffered I/O圖9 插樁進行緩沖I/O

5.2 實驗結果

根據設計，IAT工具可以分析call graph,function profile,coverage,control flow等.為減少IAT工具分析數據量，本文將CoreMark的迭代次數設置為3次后通過IAT工具分析日志記錄，產生的結果為：

1) 函數調用關系

通過IAT工具，實驗分析得出CoreMark的main函數調用關系，如圖10～12所示.圖11和圖12為圖10中的子函數，其中圖11展示了本文對CoreMark的移植方法.

Fig. 10 Function main call graph圖10 函數main調用圖

Fig. 11 Function portable_init call graph圖11 函數portable_init調用圖

Fig. 12 Function core_list_mergesort call graph圖12 函數core_list_mergesort調用圖

和使用程序源碼分析調用關系不同的是，動態分析得出的調用關系僅僅包含軟件運行時覆蓋到的調用.但是，實驗表明，動態分析函數調用關系具有自己的特點，那就是它可解算出使用函數指針調用的子函數.如圖12所示，函數core_list_mergsort通過指針調用了2個鏈表項比較函數cmp_idx和cmp_complex.

2) 函數剖面分析

通過IAT工具，實驗分析得出CoreMark和移植函數中，消耗CPU時間最多前5名依次是core_state_transition,crcu8,core_list_find,core_bench_state,core_list_mergesort,分別消耗的指令計數是427 966,135 551,79 578,33 960,33 787，分別占總運行時間55%,17%,10%,4%,4%.如圖13所示.分析完成后，軟件設計者可根據上述信息進行軟件優化.

Fig. 13 Function profile圖13 函數剖面分析示意圖

3) 覆蓋分析

通過IAT工具，實驗分析得出CoreMark函數和移植函數共計79個，在執行中共覆蓋其中52個函數，覆蓋率為65.82%.如圖14所示，圖14中縱坐標為CoreMark中的函數，橫坐標值為1的函數表示該函數為執行路徑所覆蓋，反之值為0的函數表示該函數未被執行路徑所覆蓋.

通過IAT工具，實驗分析得出CoreMark共計包含1192個可執行編譯單元，其中444個單元為執行所覆蓋，覆蓋率為37.24%.如圖15所示，圖15中縱坐標為(file,line,column)三元組，橫坐標通過1和0分別表示該三元組標識的語句塊執行與否.通過這些信息，可以解算軟件語句覆蓋率.如果將這些信息同源碼信息、執行控制流信息結合起來，則可以解算軟件分支覆蓋率、MC/DC覆蓋率等.由于篇幅有限，本文不再贅述.

Fig. 14 Function coverage圖14 函數覆蓋情況示意圖

Fig. 15 Branch coverage圖15 分支覆蓋情況示意圖

6 總 結

本文在QEMU的動態二進制翻譯技術的基礎上，突破基本塊中間碼動態插樁、基本塊運行時間統計、中斷對控制流影響消除等關鍵技術，對QEMU進行動態二進制插樁改造，成功完成軟件運行信息動態收集.并在此基礎上，設計了插樁日志分析工具IAT，完成了對軟件的函數調用、函數剖面分析、函數和分支覆蓋率統計等功能.實驗結果表明：通過本文的工作，可以有效解決嵌入式全系統軟件的二進制插樁問題.