江　山　王維維　蔣　龍　尚云海

1(浙江大學超大規(guī)模集成電路設計研究所　浙江 杭州 310027)2(亞德諾半導體技術(上海)有限公司軟件部　上海 200021)3(杭州中天微系統(tǒng)有限公司軟件部　浙江 杭州 310012)

?

一種快速定位bug的記錄-回放調試系統(tǒng)

江山1王維維1蔣龍2尚云海3

1(浙江大學超大規(guī)模集成電路設計研究所浙江 杭州 310027)2(亞德諾半導體技術(上海)有限公司軟件部上海 200021)3(杭州中天微系統(tǒng)有限公司軟件部浙江 杭州 310012)

嵌入式程序調試中，程序行為的不確定性加大了bug復現(xiàn)的難度，而多線程程序調試中此問題尤為嚴重。記錄-回放調試技術能有效地解決該問題，但是目前它仍然存在許多技術缺陷，比如會使程序性能下降、調試效率低等，對此提出并實現(xiàn)了一種快速定位bug的記錄-回放調試系統(tǒng)。該系統(tǒng)通過記錄多線程程序的調度事件，在整體調試時運行性能損耗不高于10%的情況下，實現(xiàn)多線程程序運行順序的精確回放功能。并且該系統(tǒng)結合進程快照技術，在回放模式下從快照點開始回放程序，能夠有效地加速bug的定位，提高調試效率，對于長運行時間的大型程序的調試幫助尤為有效。

嵌入式多線程可逆調試器進程快照線程調度bug定位

0　引　言

軟件開發(fā)中，調試往往占據了40%甚至以上的產品研發(fā)時間[1]。迭代調試是一種常見的，重要的調試手段，它通過重復程序的執(zhí)行，重現(xiàn)bug，定位bug。但是嵌入式LINUX多線程程序的行為不確定性會使得有些bug的重現(xiàn)非常困難，即使提供相同的程序輸入。程序的行為不確定性來源很多，例如實時控制信號的處理、音/視頻數(shù)據流、網絡數(shù)據包以及多線程之間的內存競爭等。

可逆調試技術提供了程序反向運行的能力[2]。其中，記錄-回放調試能有效解決程序不確定性帶來的問題。目前的多線程可逆調試技術領域的研究主要集中在提高記錄-回放調試的效率和速度上。如Honarmand在文獻[3]中針對源程序中需要加入一些調試功能代碼的情況，通過在記錄階段額外地記錄許多行為確定性事件，復用修改前程序在記錄階段生成的日志文件進行回放。Nicolas在文獻[4]中解決的是同樣的問題，文中通過在編譯時將新增的調試功能代碼與原始代碼分開，使得重新編譯后的程序的原始部分在回放階段運行不受影響的方式來實現(xiàn)。Nima為了加快回放速度，在文獻[5]中設計了一種使用硬件加速的記錄-回放調試方法。Xu Zhou為了減小記錄文件的大小，在文獻[6]中設計了一種加限制條件的記錄-回放調試方法，規(guī)定每個線程只能訪問自己的內存空間，以此降低多線程間內存競爭的幾率。Yann-Hang Lee則在文獻[7]中提出了一種回放能力可變的記錄-回放調試系統(tǒng)，這個系統(tǒng)在回放階段有最大回放模式和最小回放模式。

但是，目前沒有研究來解決縮小bug范圍，實現(xiàn)快速定位bug的問題。并且發(fā)現(xiàn)，大多數(shù)的記錄-回放調試是運行庫層面實現(xiàn)的，運行庫編譯進應用程序中，影響應用程序的開發(fā)；對于某些應用程序不通過運行時庫，直接使用的系統(tǒng)調用等事件無法捕捉。

本文提出一種快速定位bug的嵌入式多線程記錄-回放調試系統(tǒng)。該調試系統(tǒng)有如下三個特點：

1) 該系統(tǒng)提出一種新的事件記錄思路，它直接通過對多線程調度順序的記錄來實現(xiàn)多線程程序運行的準確回放。

2) 該系統(tǒng)在多線程調度事件基礎上采用進程快照技術，在回放階段從最近的快照點恢復進程，加快bug復現(xiàn)和定位。

3) 該系統(tǒng)實現(xiàn)不修改原有多線程程序、不修改運行時庫，完全不影響程序的開發(fā)。

1　記錄-回放調試系統(tǒng)的實現(xiàn)

本文提出的記錄-回放調試系統(tǒng)，在記錄階段完成線程調度事件記錄，并周期性生成進程快照；在回放階段，首先將進程切換到快照點，然后按照記錄的調度事件進行回放。

該記錄-回放調試系統(tǒng)實現(xiàn)包含兩個部分，一是host機上的交叉調試器GDB(以下簡稱host機GDB)，主要負責調試系統(tǒng)的記錄/回放模式的選擇。二是嵌入式LINUX調試平臺，該平臺分為兩個部分，一部分是用來模擬硬件系統(tǒng)的Qemu模擬器，Qemu是具有很好移植性的高效動態(tài)翻譯器，提供系統(tǒng)模式和用戶模式兩種功能，本文使用系統(tǒng)模式；另一部分是運行在Qemu模擬器上的系統(tǒng)軟件，包括嵌入式LINUX內核和gdbserver，在嵌入式交叉調試中，gdbserver作為host機GDB與嵌入式平臺的數(shù)據通道，通過remote協(xié)議與host機GDB進行數(shù)據通信，實現(xiàn)LINUX平臺嵌入式交叉調試，整體實現(xiàn)框架如圖1所示。

圖1　記錄-回放調試系統(tǒng)框架

本文為host機GDB增加三個用于記錄-回放的調試命令[8]，通過擴展的remote協(xié)議發(fā)送給嵌入式端gdbserver，分別用來啟動gdbserver的記錄/回放工作模式以及設置進程快照的生成周期。針對嵌入式LINUX調試平臺上的系統(tǒng)軟件，本文提出了gdbserver對記錄-回放調試功能的擴展方案，為原有gdbserver增加日志管理模塊，該模塊在記錄模式下對多線程的線程間調度順序以及進程快照進行記錄，并在回放模式下首先根據快照恢復程序，然后為gdbserver提供線程運行的順序，實現(xiàn)回放；嵌入式LINUX內核方面，本文擴展了用于調試的PTRACE系統(tǒng)調用接口，并改進調度模塊，使之能夠捕捉到線程調度事件的發(fā)生、獲取進程快照信息。針對嵌入式平臺上的Qemu模擬器，本文在原有模擬器的基礎上增加trace模塊，用于統(tǒng)計線程在用戶態(tài)走過的指令數(shù)。

整個設計分為多個獨立的模塊，每個模塊功能簡單，易于實現(xiàn)。因為繞開了對運行時庫函數(shù)的封裝，所以設計工作量較小。最終多線程應用程序不需要任何改動即可在該框架運行。

1.1host機GDB

本文通過GDB內部提供的add_setshow_boolean_cmd()接口，為host機GDB增加如下三個命令：

set record-mode on

set replay-mode on

set snap-period xxx

分別用來啟動嵌入式LINUX調試平臺的記錄模式與回放模式，以及將快照生成周期設置為xxx(累計xxx次調度事件記錄后生成一次進程快照)。

該命令擴展與gdbserver通信的remote協(xié)議，添加記錄運行程序的命令包和回放運行程序的命令包。在嵌入式gdbserver端也需要根據remote協(xié)議完善相應命令包的解析工作。

1.2嵌入式LINUX內核和gdbserver

1.2.1記錄模式

記錄模式下的工作包括記錄線程調度事件以及周期性生成進程快照。

線程調度事件記錄的基本邏輯是捕捉到調試線程被內核調度出去的時刻，然后將該時刻下目標線程的位置記錄在log文件中，如圖2所示。本文將線程被內核調度的行為定義為調度事件，線程被調度表示調度事件的發(fā)生。當調度事件發(fā)生時，需要記錄線程此時運行的位置，但不能僅記錄線程pc值，因為僅憑pc值在是不能確定線程運行的位置的(如循環(huán)邏輯)，log文件如下格式記錄： tid:調度事件發(fā)生時，被調度的線程id；user_pc_count:調度事件發(fā)生時，本線程在用戶態(tài)已經走過的指令數(shù)。

圖2　線程調度順序記錄原理

根據上述格式，LINUX內核在記錄模式下記錄調度事件發(fā)生時被調試線程的準確位置并緩存，最終gdbserver的日志管理模塊獲取該數(shù)據，保存到log文件中。

上述邏輯中有兩個關鍵點：一是調度事件的產生和捕獲；二是LINUX內核獲取user_pc_count的值。

對于進程快照的記錄，首先用戶通過gdb命令設置好snap-period，gdbserver對記錄的調度事件進行計數(shù)，當計數(shù)滿snap-period之后就發(fā)起一次進程快照記錄，記錄在snap文件中。

進程快照需要記錄的信息包括：可執(zhí)行文件的代碼、數(shù)據段內容、進程的堆區(qū)、各個線程的棧、寄存器、待處理的信號以及進程打開的文件。

記錄模式通過對LINUX內核PTRACE系統(tǒng)調用進行擴展實現(xiàn)，為gdbserver在記錄模式下運行線程時提供記錄模式運行接口[9]，見表1所示?；诂F(xiàn)有LINUX調度原理[10]。首先，對LINUX調度單元進行修改，進入調度單元后，若當前線程是記錄模式下運行的線程，內核會緩存此線程的user_pc_count，然后向此線程發(fā)送信號。由于該線程處在被調試狀態(tài)，信號在該線程被調度后會被gdbserver進程捕獲，隨后gdbserver的日志管理模塊調用PTRACE系統(tǒng)調用，獲取內核緩存下的user_pc_count，記錄值日志文件中，并且對線程調度事件進行計數(shù)，如果達到snap-period，那么發(fā)起PTRACE系統(tǒng)調用獲取進程快照，保存進程快照到snap文件中。整個流程如圖3所示。

表1　PTRACE系統(tǒng)調用擴展以及功能說明

圖3　記錄模式流程

針對user_pc_count的值，本文對Qemu模擬器的系統(tǒng)模式進行擴展，實現(xiàn)trace模塊，該模塊可以統(tǒng)計特定線程在用戶態(tài)所走過的指令數(shù)，具體參見1.3節(jié)Qemu模擬器部分。

1.2.2回放模式

回放模式工作分為兩部分，首先根據snap文件中的進程快照恢復進程；其次根據log文件中的線程調度順序控制程序回放運行。

圖4　添加snap加載方式

進程快照的恢復基于gdb在建立調試進程時進行execve()系統(tǒng)來實現(xiàn)。該系統(tǒng)調用的加載可執(zhí)行文件，將進程放入調度隊列中。該系統(tǒng)調用的關鍵數(shù)據結構是struct linux_binfmt，保存可執(zhí)行文件的加載方法。每種可執(zhí)行文件都對應一個linux_binfmt結構體。這些結構體形成一個format鏈表。本文自定義snap文件格式是基于elf文件格式的可執(zhí)行文件，可以為其添加一個linux_binfmt結構體[11]，如圖4所示。然后將snap文件作為execve()系統(tǒng)調用的參數(shù)，使用binfmt_snap加載方式。

進程快照恢復完畢，gdbserver的日志管理模塊根據記錄階段產生的log文件，組織線程間運行順序，然后gdbserver根據運行順序和運行指令數(shù)，依次運行每個線程，整個邏輯見圖5所示。通過縮小回放的范圍，提高回放階段的效率[12]。

圖5　回放模式工作原理

回放模式下，gdbserver如何控制指定線程走過特定的指令數(shù)是關鍵點。這里不能通過指令單步的方式來控制線程的運行，那樣調試效率將會非常低，本文擴展了LINUX內核PTRACE接口，增加一個系統(tǒng)調用來完成此功能，請求類型為PTRACE_CON_XINSNS，對應PTRACE值為21。該系統(tǒng)調用的功能是運行目標線程，使之在用戶態(tài)運行n條指令。

為了實現(xiàn)此功能，本文對Qemu模擬器進行了擴展，實現(xiàn)trace模塊，該模塊可以指定線程運行特定指令數(shù)。詳見1.3節(jié)。

每次調度事件的回放，首先由gdbserver通過擴展PTRACE系統(tǒng)調用向內核發(fā)起運行目標線程N條指令的要求，內核會在運行該線程之前設定Qemu的trace模塊，然后運行線程；當線程運行完成指定指令數(shù)之后，trace模塊會產生異常，LINUX內核異常處理中會向該線程發(fā)送信號，由于線程處于被調試狀態(tài)，gdbserver會捕獲該信號，至此，gdbserver完成了一次記錄在日志文件中的調度事件的模擬，整個流程如圖6所示。

圖6　調度事件回放框架

1.3Qemu模擬器

為了實現(xiàn)記錄-回放的功能，本文為Qemu模擬器增加trace模塊。該模塊完成兩個功能：一是統(tǒng)計特定線程在用戶態(tài)走過的指令數(shù)；二是統(tǒng)計工作完成后產生異常。

本文通過協(xié)處理器的方式為Qemu加入該功能模塊，最終，提供給LINUX操作系統(tǒng)的是一些通用的協(xié)處理器指令。

實現(xiàn)方案的基本思路是在指令翻譯的時候去建立target指令與本地機指令之間的映射關系，然后在執(zhí)行模塊中根據這種映射關系完成指令的統(tǒng)計功能。本文在Qemu模擬器的TCG模塊中的每個TB末尾增加一條本地指令，實現(xiàn)鉤子函數(shù)，該函數(shù)用于統(tǒng)計本TB塊的指令信息[13]。在執(zhí)行模塊中，每當執(zhí)行一個TB，就會進入預設的統(tǒng)計函數(shù)中做trace工作。在回放模式時，當執(zhí)行完指定指令數(shù)時，異常處理模塊會引發(fā)一個trace異常，由LINUX系統(tǒng)調用來處理該異常，整個實現(xiàn)框架如圖7所示。

圖7　Qemu模擬器trace功能擴展框架

2　實驗與評估

針對本文設計的所做實驗主要考察兩個指標：1) 在不采取進程快照的情況下，基于調度事件的記錄-回放調試系統(tǒng)對程序運行性能的影響；2) 測試快照的生成時間、快照的snap文件大小以及快照恢復耗時。

實驗使用LTP benchmark來評價本記錄-回放調試系統(tǒng)，該benchmark有多個不同的多線程運行方式，這里選擇了一些經典、常用的多線程模式來評價該調試系統(tǒng)。本次試驗所用軟件環(huán)境為Linux 2.6.9-101.ELlargesmp，gcc版本是3.4.6.硬件環(huán)境為實驗室所用服務器，Intel(R) Xeon(R) X5690， CPU主頻3.47 GHz，24核，64G內存。

如圖8、圖9所示。實驗記錄了在不采用程序快照時，調試器系統(tǒng)工作在記錄模式下時和工作在回放模式下時運行多線程的時間與多線程本身運行時間的比較結果，通過8組LTP benchmark的測試結果得出，在記錄模式下，多線程程序運行平均時間是正常運行的1.045倍，而在回放模式下，多線程程序平均運行速度是正常運行速度的1.145倍。

圖8　記錄-回放調試系統(tǒng)實驗結果(無單位)

圖9　記錄-回放調試系統(tǒng)實驗結果(續(xù))(無單位)

快照的生成時間、快照的snap文件大小以及快照的恢復時間，和線程的數(shù)目以及程序本身有關系。取平均數(shù)據，快照生成時間為7.5 ms，snap文件大小為3.1 MB，快照恢復時間為9.3 ms。

假設程序的標準運行時間為T，在記錄過程中產生了n次進程快照；回放階段，如果沒有快照從頭開始運行，按照實驗結果回放時間耗時t1；在使用n次進程快照的情況下回放耗時t2。那么用戶對于進程快照周期的選擇應該滿足下列條件：

t1=1.145T

(1)

(2)

t2

(3)

由實驗結果可知，當被調試程序運行時間較長，達到秒級時，本文設計的調試系統(tǒng)對于bug定位速度提高顯著。而且，通常情況下，在調試過程中，一次記錄要回放多次。所以在實際應用中，采用本文設計進程快照與調度事件結合的記錄-回放調試模式，在消除多線程程序的行為不確定性的基礎上，能有效減少回放時間，加速定位bug，提高調試效率。

3　結　語

針對嵌入式多線程軟件調試的困難，本文設計了一款記錄-回放調試器，并在C-SKY平臺[14]上進行了實現(xiàn)。實驗結果與預期基本一致，效果良好，實現(xiàn)了對bug的快速定位，提高了多線程程序的調試效率。

本次設計中，對于外部激勵需要保證，回放階段的程序外部激勵要與記錄階段一致，這是本次設計中沒有解決的問題。下一階段需要在現(xiàn)有框架下做擴展，增加在回放階段對外部激勵進行回放的功能。多核架構中，并行程序的行為不確定問題更加突出[15]，下一步工作研究多核的可逆調試技術。

[1] Gregory Tassey.The economic impacts of inadequate infrastructure for software testing[R].U.S Department of Commerce,Tech Rep:RTI7007.011,2002.

[2] Jakob Engblom.A review of reverse debugging[C]//System,Software,SoC and Silicon Debug Conference (S4D).Vienna:IEEE,2012:1-6.

[3] Honarmand Nima,Josep Torrellas.Replay Debugging:Leveraging Record and Replay for Program Debugging[C]//International Symposium on Computer Architecture (ISCA).Minneapolis,USA:IEEE,2014:455-456.

[4] Nicolas Viennot,Siddharth Nair,Jason Nieh.Transparent mutable replay for multicore debugging and patch validation[C]//Proceedings of the eighteenth International conference on Architectural support for programming languages and operating systems.NewYork,USA:ACM SIGARCH,2013:127-138.

[5] Nima Honarmand,Nathan Dautenhahn,Josep Torrellas.Cyrus:unintrusive application-level record-replay for replay parallelism[C]//Proceedings of the eighteenth International conference on Architectural support for programming languages and operating systems.NewYork,USA:ACM SIGARCH,2013:193-206.

[6] Xu Zhou,Kai Lu,Xicheng Lu,et al.RReplay:A record & replay system based on restricted multi-threading[C]//2012 International Conference on Computer Science & Service System (CSSS).NanJing,China:IEEE,2012:2247-2250.[7] YannHang Lee,Young Wn Song,Rohit Girme,et al.Replay Debugging for Multi-threaded Embedded Software[C]//2010 IEE/IFIP 8thInternational Conference on Embeded and Ubiquitious Compting (EUC).Hong Kong,China:IEEE,2010:15-22.

[8] 邵騰岡,張俊飛.基于虛擬機日志記錄回放的可逆調試方法[J].計算機應用與軟件,2011,28(4):140-142.

[9] 陳必泉,黃承慧.GDBSERVER原理分析及其應用[J].計算機工程與設計,2005,26(3):746-749.

[10] 雷銘哲,張勇.Linux線程機制研究[J].火力與指揮控制,2010,35(2):112-118.

[11] 羅琰.基于內核模式下進程快照的可回溯調試研究及初步實現(xiàn)[D].杭州:浙江大學,2008.

[12] Yan Wang,Harish Pati.Dr Debug:Deterministic Replay based Cyclic Debugging with Dynamic Slicing[C]//Proceedings of A nnual IEEE/ACM International Symposium on Code Generation and Optimization.New York,USA:ACM,2014:98-98.

[13] Pavel Dovgalyuk.Deterministic Replay of System’s Execution with Multi-target QEMU Simulator for Dynamic Analysis and Reverse Debugging[C]//2012 16thEuropean Conference on software Maintenance and Reengineering(CSMR).Szeged Hungary:IEEE,2012:553-556.

[14] 潘赟.CK-CPU嵌入式系統(tǒng)開發(fā)教程[M].北京:科學出版社,2011.

[15] Nima Honarmand.Record And Deterministic replay of parallel programs on multiprocessors[D].Illinois:University of Illinois Urbana-Champaign,2014.

A FAST BUG-LOCATING RECORD AND REPLAY DEBUGGING SYSTEM

Jiang Shan1Wang Weiwei1Jiang Long2Shang Yunhai3

1(InstituteofVLSIDesign,ZhejiangUniversity,Hangzhou310027,Zhejiang,China)2(DepartmentofSoftware,AnalogDevicesInc(Shanghai),Shanghai200021,China)3(DepartmentofSoftware,C-SKYMicrosystems,Co.,LTD,Hangzhou310012,Zhejiang,China)

While debugging embedded Linux, the uncertainty of program behaviour increases the difficulty of bug reproduction, and this is particularly serious in debugging multi-thread programs. Record and replay debugging technology is can effectively solve this problem, but at present it still has a couple of technical flaws, such as degrading program performance and low debugging efficiency, etc. In this paper we present and implement a fast bug-locating record and replay debugging system. By recording the scheduling events of multi-thread program, it realises the function of accurate multi-thread program operation order replay under the condition of less than 10% of performance loss in overall debugging. In addition, this debugging system, incorporating process snapshot, can effectively speed up bug locating by commencing the replay program from snapshot point in replay mode. This improves the efficiency of debugging, and is effective particularly in debugging large-scale program with long running time.

EmbeddedMulti-threadReverse debuggerProcess snapshotThread schedulingBug-locating

2015-07-26。核高基重大專項(2010ZX01030-001-001-002)。江山，碩士生，主研領域：嵌入式工具軟件研究。王維維，副教授。蔣龍，工程師。尚云海，工程師。

TP311

A

10.3969/j.issn.1000-386x.2016.10.049