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

江　山　王維維　蔣　龍　尚云海

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

?

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

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

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

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

嵌入式多線程可逆調(diào)試器進程快照線程調(diào)度bug定位

0　引　言

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1host機GDB

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

set record-mode on

set replay-mode on

set snap-period xxx

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

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

1.2嵌入式LINUX內(nèi)核和gdbserver

1.2.1記錄模式

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

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

圖2　線程調(diào)度順序記錄原理

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

上述邏輯中有兩個關(guān)鍵點：一是調(diào)度事件的產(chǎn)生和捕獲；二是LINUX內(nèi)核獲取user_pc_count的值。

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

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

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

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

圖3　記錄模式流程

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

1.2.2回放模式

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

圖4　添加snap加載方式

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

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

圖5　回放模式工作原理

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

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

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

圖6　調(diào)度事件回放框架

1.3Qemu模擬器

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

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

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

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

2　實驗與評估

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

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

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

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

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

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

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

t1=1.145T

(1)

(2)

t2

(3)

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

3　結(jié)　語

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

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

[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] 邵騰岡,張俊飛.基于虛擬機日志記錄回放的可逆調(diào)試方法[J].計算機應(yīng)用與軟件,2011,28(4):140-142.

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

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

[11] 羅琰.基于內(nèi)核模式下進程快照的可回溯調(diào)試研究及初步實現(xiàn)[D].杭州:浙江大學(xué),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].北京:科學(xué)出版社,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)。江山，碩士生，主研領(lǐng)域：嵌入式工具軟件研究。王維維，副教授。蔣龍，工程師。尚云海，工程師。

TP311

A

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