RTEMS任務(wù)級別調(diào)試技術(shù)研究
調(diào)試一直是嵌入式系統(tǒng)開發(fā)的難題。開發(fā)者往往直接面對嵌入式開發(fā)硬件進行開發(fā),就算目標嵌入式環(huán)境中引入了操作系統(tǒng),其功能通常也有一定的限制,不能方便地進行調(diào)試。而且,引入嵌入式操作系統(tǒng)的過程中的調(diào)試問題也很棘手。遠程調(diào)試是解決此類問題的首選方案。
RTEMS操作系統(tǒng)是當今應(yīng)用廣泛的開源實時操作系統(tǒng)。本文將以RTEMS操作系統(tǒng)為討論背景,介紹RTEMS操作系統(tǒng)環(huán)境下,如何使用GDB來完成系統(tǒng)的任務(wù)級調(diào)試工作。
1 RTEMS操作系統(tǒng)簡介
RTEMS,即實時多處理器系統(tǒng)(Real Time Executivefor Multiprocessor Systems),是一個開源的實時嵌入式操作系統(tǒng)。它最早用于美國國防系統(tǒng),現(xiàn)在它在航空航天、軍工及民用領(lǐng)域都有著廣泛的應(yīng)用。
從結(jié)構(gòu)上來看,RTEMS是微內(nèi)核搶占式實時系統(tǒng)。圖1顯示了RTEMS操作系統(tǒng)的基本結(jié)構(gòu)。圖中白色部分為RTEMS操作系統(tǒng)的硬件支持部分(Board SupportPackage),它包括了硬件抽象代碼、硬件設(shè)備驅(qū)動代碼和操作系統(tǒng)啟動代碼?;疑糠譃镽TEMS內(nèi)核以及系統(tǒng)提供給應(yīng)用程序的API。在具體應(yīng)用場景中,圖中所有系統(tǒng)模塊都被編譯成一個靜態(tài)連接庫,用戶編寫的應(yīng)用程序和RTEMS庫靜態(tài)鏈接成一個整體,形成運行在目標環(huán)境的鏡像文件。應(yīng)用程序只將需要的系統(tǒng)支持模塊鏈接進來,最大程度地縮小了可執(zhí)行鏡像的大小。
此外,RTEMS十分簡潔,力求實時性。它不支持虛擬內(nèi)存,整個系統(tǒng)內(nèi)核以及應(yīng)用程序運行在共同的平板內(nèi)存空間之上。因此,RTEMS鏡像文件的運行可以看作是一個大型的、處理時鐘中斷的裸板程序。
2 GDB遠程調(diào)試
GDB全稱GNU symbolic debugger。在大多數(shù)情況下,在UNIx或者Linux環(huán)境下使用GDB調(diào)試本機程序,GDB通過waitpid、ptrace等系統(tǒng)調(diào)用對被調(diào)試進程進行監(jiān)查和控制。這種調(diào)試模式很常見,但它只是GDB調(diào)試的一種特殊情況:GDB本身的運行環(huán)境和被調(diào)試程序的運行環(huán)境恰巧是同一個。在有些情況下,被調(diào)試程序運行環(huán)境下可能無法方便地運行GDB,那么遠程調(diào)試就會派上用場。
2.1 遠程調(diào)試中程序的交互途徑
如圖2所示,GDB和被調(diào)試程序運行于不同的環(huán)境中。在GDB加載了和被調(diào)試程序?qū)?yīng)的調(diào)試信息之后,用戶可以通過它對被調(diào)程序進行源代碼級調(diào)試。用戶向GDB下達調(diào)試命令,GDB將用戶的調(diào)試命令翻譯、打包,通過串口或者網(wǎng)絡(luò)接口發(fā)送至被調(diào)試程序端的GDB—SERVER。GDB—SERVER將接收到的調(diào)試命令包解包,并將其表達的調(diào)試命令實施于被調(diào)試程序。如果需要,還應(yīng)將命令執(zhí)行結(jié)果通過遠程通信返回給GDB端。
2.2 GDB與GDB—SERVER
GDB和GDB—SERVER之間的數(shù)據(jù)通道上傳輸?shù)男畔⒆裱璆DB Remote Serial Protocol。它是一種簡潔的、基于ASCII的協(xié)議。每一個RSP報文由ASCII符號“$”開頭,由“#”將報文內(nèi)容和兩個字節(jié)的報文校驗隔開,如下所示:
接收方對報文進行校驗,如果校驗成功,回復(fù)ASCII字符“+”,否則回復(fù)“一”。
通過RSP傳輸?shù)拿罘N類很多,比較常用的羅列于表1中。當用戶使用GDB遠程調(diào)試程序時,GDB將用戶的命令翻譯成若干條RSP命令的序列下達給GDB—SERVER。GDB—SERVER對命令進行實施,并回復(fù)運行結(jié)果。作為一個能實現(xiàn)基本調(diào)試功能的GDB—SERVER,至少需要實現(xiàn)表1中列出的命令。
2.3 GDB—SERVER與被調(diào)試程序
GDB—SERVER和被調(diào)試程序之間的交互方式就比較靈活了,在沒有虛擬內(nèi)存管理的環(huán)境中可以使用指針直接訪問被調(diào)試程序的內(nèi)存,而在引入了嵌入式操作系統(tǒng)的環(huán)境中可以使用系統(tǒng)調(diào)用實現(xiàn)。GDB—SERVER是GDB調(diào)試命令的實施者,依照GDB的調(diào)試基本需求,GDB—SERVER和被調(diào)試程序之間的交互方式只要能夠完成表1中列出的操作就可以了。
3 傳統(tǒng)STUB調(diào)試模式概述
GDB—STUB是嵌入在被調(diào)試程序中的小段程序,它肩負了和GDB通信并執(zhí)行GDB調(diào)試命令的重任。可以說GDB—STUB是輕量級的GDB—SERVER。它代碼量很少,在RTEMS啟動初始化階段,將它以軟中斷處理程序的身份嵌入到RTEMS之中,成為RTEMS的一部分。當被調(diào)試程序運行到這個特殊的軟中斷時,STUB程序獲得運行的權(quán)力,和GDB進行遠程通信,執(zhí)行調(diào)試命令,直到收到被調(diào)試程序繼續(xù)執(zhí)行的命令,STUB恢復(fù)被調(diào)試程序的執(zhí)行,如圖3所示。
由于它和被調(diào)試程序融為一體,所以它可以直接訪問被調(diào)試程序的內(nèi)存地址,查詢或者修改被調(diào)試程序內(nèi)存空間的值。
此方法將RTEMS系統(tǒng)看作一個嵌入式裸板程序,可以在源碼級別對整個RTEMS系統(tǒng)進行調(diào)試??梢韵胂?,此時GDB根本不知道被調(diào)試程序是一個操作系統(tǒng),一旦STUB獲得了執(zhí)行機會,整個RTEMS系統(tǒng)進入暫停狀態(tài),無論系統(tǒng)中運行的是應(yīng)用還是系統(tǒng)內(nèi)核本身。而調(diào)試系統(tǒng)本身遠遠沒有調(diào)試系統(tǒng)中應(yīng)用程序的需求量大,在調(diào)試應(yīng)用的時候,希望只是被調(diào)試的任務(wù)暫停,系統(tǒng)中其他任務(wù)不受我們調(diào)試行為的影響。下文將介紹RTEMS任務(wù)級別的GDB遠程調(diào)試方法。
[!--empirenews.page--]4 面向任務(wù)的RTEMS調(diào)試
為了實現(xiàn)面向RTEMS任務(wù)的調(diào)試手段,將調(diào)試相關(guān)服務(wù)抽象成RTEMS任務(wù)和RTEMS中斷處理程序。這樣調(diào)試服務(wù)也將作為任務(wù)被RTEMS系統(tǒng)調(diào)度,當沒有調(diào)試需求的時候,這些任務(wù)處于不可調(diào)度狀態(tài),不影響整個系統(tǒng)的運行。調(diào)試服務(wù)由以下三部分組成:
初始化任務(wù),負責整個RTEMS調(diào)試服務(wù)的啟動。
命令處理任務(wù),與GDB交互,執(zhí)行命令,并回復(fù)執(zhí)行結(jié)果。
事件處理程序,獲取任務(wù)中斷信號,通知GDB被調(diào)試任務(wù)的狀態(tài)。
這三部分的邏輯關(guān)系如圖4所示。
4.1 調(diào)試任務(wù)說明
(1)初始化任務(wù)
初始化任務(wù)負責整個RTEMS調(diào)試服務(wù)的啟動。它首先對GDB和調(diào)試服務(wù)之間的通信路徑(串口或者網(wǎng)絡(luò)接口)進行初始化,然后建立命令處理任務(wù),并將事件處理程序與對應(yīng)的軟中斷掛接起來。在初始化一切正常的情況下,初始化任務(wù)的歷史使命徹底完成,它將自己刪除。
(2)命令處理任務(wù)
命令處理任務(wù)由初始化任務(wù)建立。當GDB有命令到來的時候它被喚醒,接受命令,執(zhí)行命令,并將執(zhí)行結(jié)果發(fā)送回GDB。
現(xiàn)在整個調(diào)試服務(wù)都建立在RTEMS任務(wù)機制之上,又由于RTEMS支持POSIX接口規(guī)范,在“執(zhí)行命令”階段使用ptrace之類的系統(tǒng)調(diào)用來控制被調(diào)試任務(wù)是更好的選擇。它可以降低調(diào)試服務(wù)和硬件平臺的關(guān)聯(lián)性,易于調(diào)試服務(wù)的移植和擴展。
在GDB發(fā)送繼續(xù)執(zhí)行命令(c命令或者s命令)的時候,命令處理程序?qū)θ中盘柫緿ebugEvent進行一次V操作,使被調(diào)試程序成為可調(diào)度任務(wù)。
(3)事件處理程序
事件處理程序不是一個任務(wù),而是一個軟中斷處理程序。當被調(diào)試程序遇到斷點(軟中斷命令)的時候,處理器會轉(zhuǎn)到事件處理程序上來。在STUB調(diào)試模式中,基本所有調(diào)試功能都在這個程序中完成,這就阻礙了RTEMS系統(tǒng)以及系統(tǒng)中其他任務(wù)的運行。
現(xiàn)在,事件處理程序只是報告GDB被調(diào)試程序中斷發(fā)生,然后將對全局信號量DebugEvent進行一次P操作,使被調(diào)試任務(wù)進入不可調(diào)度狀態(tài)。
在此要注意軟中斷的性質(zhì),它不同于真正的外部中斷。用操作系統(tǒng)接口的概念來類比將更容易理解:當遇到一個軟中斷的時候,RTEMS將堆棧轉(zhuǎn)換成對應(yīng)任務(wù)的系統(tǒng)堆棧,但是此時仍然處于任務(wù)上下文當中,那么當然也就可以在事件處理程序中睡眠。
4.2 調(diào)試任務(wù)同步關(guān)系
通過任務(wù)優(yōu)先等級和信號量來維持調(diào)試系統(tǒng)任務(wù)之間的同步關(guān)系。
首先,初始化任務(wù)和命令處理任務(wù)擁有相同的優(yōu)先級——RTEMS中最高的優(yōu)先級,其他所有應(yīng)用的優(yōu)先級都要低于此優(yōu)先級,不能等于。這樣就保證了GDB送來調(diào)試命令的時候,命令處理任務(wù)能夠及時反應(yīng)。
其次,使用全局DebugEvent信號量來控制被調(diào)試任務(wù)的調(diào)度狀態(tài)。每次遇到斷點,被調(diào)試任務(wù)進入事件處理程序(可看作是一個系統(tǒng)調(diào)用陷入)中,阻塞在事件處理程序的P操作之上。當命令處理任務(wù)收到被調(diào)試任務(wù)繼續(xù)執(zhí)行的命令時,對DebtagEvent信號量進行V操作,使被調(diào)試任務(wù)重新可調(diào)度。
最終調(diào)試服務(wù)的運行狀態(tài)是:初始化任務(wù)在系統(tǒng)運行之初就刪除了自己;在GDB不發(fā)送命令的時候,命令處理任務(wù)處于阻塞態(tài),此時,RTEMS系統(tǒng)正常運行。當被調(diào)試任務(wù)遇到斷點的時候,被調(diào)試任務(wù)阻塞在對Debu—gEvent信號量的P操作上,GDB得到被調(diào)試任務(wù)狀態(tài)變化的通知,用戶開始下達調(diào)試命令。GDB通過RSP傳送給被調(diào)試端的每一條命令,都會將命令處理任務(wù)喚醒。命令處理位務(wù)迅速執(zhí)行命令,將執(zhí)行結(jié)果回復(fù),然后重新進入到阻塞狀態(tài),等待下一條命令的到來。如果收到被調(diào)試任務(wù)繼續(xù)執(zhí)行的命令,命令處理任務(wù)對DebugEvent信號量進行V操作,使被調(diào)試任務(wù)得以繼續(xù)被調(diào)度。
4.3 其他相關(guān)問題
第一個斷點:為了不讓被調(diào)試任務(wù)一下子運行到結(jié)尾(不給調(diào)試服務(wù)任何的執(zhí)行機會),需要在被調(diào)試任務(wù)的開頭以手工修改代碼的方式加入第一個斷點。斷點往往就是一個指定的軟中斷匯編指令(以i386為例,軟中斷對應(yīng)匯編指令“int 3”)。此時,用戶可以通過GDB遠程下達調(diào)試命令,對被調(diào)程序進行正常調(diào)試,并設(shè)置后繼的斷點??烧{(diào)試代碼范圍:首先,調(diào)試服務(wù)中用到的代碼都是不可以被設(shè)置斷點的,這樣會引起調(diào)試服務(wù)的遞歸調(diào)用,系統(tǒng)會直接崩潰。其次,要避免在多個任務(wù)重入的代碼中設(shè)置斷點,這樣有可能多個任務(wù)向GDB匯報遇到了斷點,產(chǎn)生混亂。
結(jié) 語
本文對RTEMS操作系統(tǒng)的調(diào)試手段進行了探討。其中STUB調(diào)試方式比較成熟,可以參考GDB源碼中的./gdb/i386一stub.c來理解STUB的工作方式。在此基礎(chǔ)上,本文提出了面向任務(wù)的調(diào)試方式,在思路上延續(xù)STUB的路線,將調(diào)試服務(wù)分散到RTEMS任務(wù)和RTEMS軟中斷服務(wù)中去,實現(xiàn)了簡單實用的面向任務(wù)的RTEMS調(diào)試手段。