基于RTEMS操作系統(tǒng)實(shí)現(xiàn)面向任務(wù)的調(diào)試方法分析

作者：黨建勛，尚利宏，李紅兵

引言

調(diào)試一直是嵌入式系統(tǒng)開(kāi)發(fā)的難題。開(kāi)發(fā)者往往直接面對(duì)嵌入式開(kāi)發(fā)硬件進(jìn)行開(kāi)發(fā)，就算目標(biāo)嵌入式環(huán)境中引入了操作系統(tǒng)，其功能通常也有一定的限制，不能方便地進(jìn)行調(diào)試。而且，引入嵌入式操作系統(tǒng)的過(guò)程中的調(diào)試問(wèn)題也很棘手。遠(yuǎn)程調(diào)試是解決此類(lèi)問(wèn)題的首選方案。

RTEMS操作系統(tǒng)是當(dāng)今應(yīng)用廣泛的開(kāi)源實(shí)時(shí)操作系統(tǒng)。本文將以RTEMS操作系統(tǒng)為討論背景，介紹RTEMS操作系統(tǒng)環(huán)境下，如何使用GDB來(lái)完成系統(tǒng)的任務(wù)級(jí)調(diào)試工作。

1 RTEMS操作系統(tǒng)簡(jiǎn)介

RTEMS，即實(shí)時(shí)多處理器系統(tǒng)（Real Time Executivefor Multiprocessor Systems），是一個(gè)開(kāi)源的實(shí)時(shí)嵌入式操作系統(tǒng)。它最早用于美國(guó)國(guó)防系統(tǒng)，現(xiàn)在它在航空航天、軍工及民用領(lǐng)域都有著廣泛的應(yīng)用。

從結(jié)構(gòu)上來(lái)看，RTEMS是微內(nèi)核搶占式實(shí)時(shí)系統(tǒng)。圖1顯示了RTEMS操作系統(tǒng)的基本結(jié)構(gòu)。圖中白色部分為RTEMS操作系統(tǒng)的硬件支持部分 （Board SupportPackage），它包括了硬件抽象代碼、硬件設(shè)備驅(qū)動(dòng)代碼和操作系統(tǒng)啟動(dòng)代碼?；疑糠譃镽TEMS內(nèi)核以及系統(tǒng)提供給應(yīng)用程序的 API。在具體應(yīng)用場(chǎng)景中，圖中所有系統(tǒng)模塊都被編譯成一個(gè)靜態(tài)連接庫(kù)，用戶編寫(xiě)的應(yīng)用程序和RTEMS庫(kù)靜態(tài)鏈接成一個(gè)整體，形成運(yùn)行在目標(biāo)環(huán)境的鏡像文件。應(yīng)用程序只將需要的系統(tǒng)支持模塊鏈接進(jìn)來(lái)，最大程度地縮小了可執(zhí)行鏡像的大小。

此外，RTEMS十分簡(jiǎn)潔，力求實(shí)時(shí)性。它不支持虛擬內(nèi)存，整個(gè)系統(tǒng)內(nèi)核以及應(yīng)用程序運(yùn)行在共同的平板內(nèi)存空間之上。因此，RTEMS鏡像文件的運(yùn)行可以看作是一個(gè)大型的、處理時(shí)鐘中斷的裸板程序。

2 GDB遠(yuǎn)程調(diào)試

GDB全稱(chēng)GNU symbolic debugger。在大多數(shù)情況下，在UNIx或者Linux環(huán)境下使用GDB調(diào)試本機(jī)程序，GDB通過(guò)waitpid、ptrace等系統(tǒng)調(diào)用對(duì)被調(diào)試進(jìn)程進(jìn)行監(jiān)查和控制。這種調(diào)試模式很常見(jiàn)，但它只是GDB調(diào)試的一種特殊情況：GDB本身的運(yùn)行環(huán)境和被調(diào)試程序的運(yùn)行環(huán)境恰巧是同一個(gè)。在有些情況下，被調(diào)試程序運(yùn)行環(huán)境下可能無(wú)法方便地運(yùn)行GDB，那么遠(yuǎn)程調(diào)試就會(huì)派上用場(chǎng)。

2．1 遠(yuǎn)程調(diào)試中程序的交互途徑

如圖2所示，GDB和被調(diào)試程序運(yùn)行于不同的環(huán)境中。在GDB加載了和被調(diào)試程序?qū)?yīng)的調(diào)試信息之后，用戶可以通過(guò)它對(duì)被調(diào)程序進(jìn)行源代碼級(jí)調(diào)試。用戶向 GDB下達(dá)調(diào)試命令，GDB將用戶的調(diào)試命令翻譯、打包，通過(guò)串口或者網(wǎng)絡(luò)接口發(fā)送至被調(diào)試程序端的GDB—SERVER。GDB—SERVER將接收到的調(diào)試命令包解包，并將其表達(dá)的調(diào)試命令實(shí)施于被調(diào)試程序。如果需要，還應(yīng)將命令執(zhí)行結(jié)果通過(guò)遠(yuǎn)程通信返回給GDB端。

2．2 GDB與GDB—SERVER

GDB和GDB—SERVER之間的數(shù)據(jù)通道上傳輸?shù)男畔⒆裱璆DB Remote Serial Protocol。它是一種簡(jiǎn)潔的、基于ASCII的協(xié)議。每一個(gè)RSP報(bào)文由ASCII符號(hào)“$”開(kāi)頭，由“#”將報(bào)文內(nèi)容和兩個(gè)字節(jié)的報(bào)文校驗(yàn)隔開(kāi)，如下所示：

接收方對(duì)報(bào)文進(jìn)行校驗(yàn)，如果校驗(yàn)成功，回復(fù)ASCII字符“+”，否則回復(fù)“一”。

通過(guò)RSP傳輸?shù)拿罘N類(lèi)很多，比較常用的羅列于表1中。當(dāng)用戶使用GDB遠(yuǎn)程調(diào)試程序時(shí)，GDB將用戶的命令翻譯成若干條RSP命令的序列下達(dá)給GDB —SERVER。GDB—SERVER對(duì)命令進(jìn)行實(shí)施，并回復(fù)運(yùn)行結(jié)果。作為一個(gè)能實(shí)現(xiàn)基本調(diào)試功能的GDB—SERVER，至少需要實(shí)現(xiàn)表1中列出的命令。

2．3 GDB—SERVER與被調(diào)試程序

GDB—SERVER和被調(diào)試程序之間的交互方式就比較靈活了，在沒(méi)有虛擬內(nèi)存管理的環(huán)境中可以使用指針直接訪問(wèn)被調(diào)試程序的內(nèi)存，而在引入了嵌入式操作系統(tǒng)的環(huán)境中可以使用系統(tǒng)調(diào)用實(shí)現(xiàn)。GDB—SERVER是GDB調(diào)試命令的實(shí)施者，依照GDB的調(diào)試基本需求，GDB—SERVER和被調(diào)試程序之間的交互方式只要能夠完成表1中列出的操作就可以了。

3 傳統(tǒng)STUB調(diào)試模式概述

GDB —STUB是嵌入在被調(diào)試程序中的小段程序，它肩負(fù)了和GDB通信并執(zhí)行GDB調(diào)試命令的重任?？梢哉f(shuō)GDB—STUB是輕量級(jí)的GDB—SERVER。它代碼量很少，在RTEMS啟動(dòng)初始化階段，將它以軟中斷處理程序的身份嵌入到RTEMS之中，成為RTEMS的一部分。當(dāng)被調(diào)試程序運(yùn)行到這個(gè)特殊的軟中斷時(shí)，STUB程序獲得運(yùn)行的權(quán)力，和GDB進(jìn)行遠(yuǎn)程通信，執(zhí)行調(diào)試命令，直到收到被調(diào)試程序繼續(xù)執(zhí)行的命令，STUB恢復(fù)被調(diào)試程序的執(zhí)行，如圖3所示。

由于它和被調(diào)試程序融為一體，所以它可以直接訪問(wèn)被調(diào)試程序的內(nèi)存地址，查詢或者修改被調(diào)試程序內(nèi)存空間的值。

此方法將RTEMS系統(tǒng)看作一個(gè)嵌入式裸板程序，可以在源碼級(jí)別對(duì)整個(gè)RTEMS系統(tǒng)進(jìn)行調(diào)試?？梢韵胂?，此時(shí)GDB根本不知道被調(diào)試程序是一個(gè)操作系統(tǒng)，一旦STUB獲得了執(zhí)行機(jī)會(huì)，整個(gè)RTEMS系統(tǒng)進(jìn)入暫停狀態(tài)，無(wú)論系統(tǒng)中運(yùn)行的是應(yīng)用還是系統(tǒng)內(nèi)核本身。而調(diào)試系統(tǒng)本身遠(yuǎn)遠(yuǎn)沒(méi)有調(diào)試系統(tǒng)中應(yīng)用程序的需求量大，在調(diào)試應(yīng)用的時(shí)候，希望只是被調(diào)試的任務(wù)暫停，系統(tǒng)中其他任務(wù)不受我們調(diào)試行為的影響。下文將介紹RTEMS任務(wù)級(jí)別的GDB遠(yuǎn)程調(diào)試方法。

4 面向任務(wù)的RTEMS調(diào)試

為了實(shí)現(xiàn)面向RTEMS任務(wù)的調(diào)試手段，將調(diào)試相關(guān)服務(wù)抽象成RTEMS任務(wù)和RTEMS中斷處理程序。這樣調(diào)試服務(wù)也將作為任務(wù)被RTEMS系統(tǒng)調(diào)度，當(dāng)沒(méi)有調(diào)試需求的時(shí)候，這些任務(wù)處于不可調(diào)度狀態(tài)，不影響整個(gè)系統(tǒng)的運(yùn)行。調(diào)試服務(wù)由以下三部分組成：

初始化任務(wù)，負(fù)責(zé)整個(gè)RTEMS調(diào)試服務(wù)的啟動(dòng)。

命令處理任務(wù)，與GDB交互，執(zhí)行命令，并回復(fù)執(zhí)行結(jié)果。

事件處理程序，獲取任務(wù)中斷信號(hào)，通知GDB被調(diào)試任務(wù)的狀態(tài)。

這三部分的邏輯關(guān)系如圖4所示。

4．1 調(diào)試任務(wù)說(shuō)明

（1）初始化任務(wù)

初始化任務(wù)負(fù)責(zé)整個(gè)RTEMS調(diào)試服務(wù)的啟動(dòng)。它首先對(duì)GDB和調(diào)試服務(wù)之間的通信路徑（串口或者網(wǎng)絡(luò)接口）進(jìn)行初始化，然后建立命令處理任務(wù)，并將事件處理程序與對(duì)應(yīng)的軟中斷掛接起來(lái)。在初始化一切正常的情況下，初始化任務(wù)的歷史使命徹底完成，它將自己刪除。

（2）命令處理任務(wù)

命令處理任務(wù)由初始化任務(wù)建立。當(dāng)GDB有命令到來(lái)的時(shí)候它被喚醒，接受命令，執(zhí)行命令，并將執(zhí)行結(jié)果發(fā)送回GDB。

現(xiàn)在整個(gè)調(diào)試服務(wù)都建立在RTEMS任務(wù)機(jī)制之上，又由于RTEMS支持POSIX接口規(guī)范，在“執(zhí)行命令”階段使用ptrace之類(lèi)的系統(tǒng)調(diào)用來(lái)控制被調(diào)試任務(wù)是更好的選擇。它可以降低調(diào)試服務(wù)和硬件平臺(tái)的關(guān)聯(lián)性，易于調(diào)試服務(wù)的移植和擴(kuò)展。

在GDB發(fā)送繼續(xù)執(zhí)行命令（c命令或者s命令）的時(shí)候，命令處理程序?qū)θ中盘?hào)量DebugEvent進(jìn)行一次V操作，使被調(diào)試程序成為可調(diào)度任務(wù)。

（3）事件處理程序

事件處理程序不是一個(gè)任務(wù)，而是一個(gè)軟中斷處理程序。當(dāng)被調(diào)試程序遇到斷點(diǎn)（軟中斷命令）的時(shí)候，處理器會(huì)轉(zhuǎn)到事件處理程序上來(lái)。在STUB調(diào)試模式中，基本所有調(diào)試功能都在這個(gè)程序中完成，這就阻礙了RTEMS系統(tǒng)以及系統(tǒng)中其他任務(wù)的運(yùn)行。

現(xiàn)在，事件處理程序只是報(bào)告GDB被調(diào)試程序中斷發(fā)生，然后將對(duì)全局信號(hào)量DebugEvent進(jìn)行一次P操作，使被調(diào)試任務(wù)進(jìn)入不可調(diào)度狀態(tài)。

在此要注意軟中斷的性質(zhì)，它不同于真正的外部中斷。用操作系統(tǒng)接口的概念來(lái)類(lèi)比將更容易理解：當(dāng)遇到一個(gè)軟中斷的時(shí)候，RTEMS將堆棧轉(zhuǎn)換成對(duì)應(yīng)任務(wù)的系統(tǒng)堆棧，但是此時(shí)仍然處于任務(wù)上下文當(dāng)中，那么當(dāng)然也就可以在事件處理程序中睡眠。

4．2 調(diào)試任務(wù)同步關(guān)系

通過(guò)任務(wù)優(yōu)先等級(jí)和信號(hào)量來(lái)維持調(diào)試系統(tǒng)任務(wù)之間的同步關(guān)系。

首先，初始化任務(wù)和命令處理任務(wù)擁有相同的優(yōu)先級(jí)——RTEMS中最高的優(yōu)先級(jí)，其他所有應(yīng)用的優(yōu)先級(jí)都要低于此優(yōu)先級(jí)，不能等于。這樣就保證了GDB送來(lái)調(diào)試命令的時(shí)候，命令處理任務(wù)能夠及時(shí)反應(yīng)。

其次，使用全局DebugEvent信號(hào)量來(lái)控制被調(diào)試任務(wù)的調(diào)度狀態(tài)。每次遇到斷點(diǎn)，被調(diào)試任務(wù)進(jìn)入事件處理程序（可看作是一個(gè)系統(tǒng)調(diào)用陷入）中，阻塞在事件處理程序的P操作之上。當(dāng)命令處理任務(wù)收到被調(diào)試任務(wù)繼續(xù)執(zhí)行的命令時(shí)，對(duì)DebtagEvent信號(hào)量進(jìn)行V操作，使被調(diào)試任務(wù)重新可調(diào)度。

最終調(diào)試服務(wù)的運(yùn)行狀態(tài)是：初始化任務(wù)在系統(tǒng)運(yùn)行之初就刪除了自己；在GDB不發(fā)送命令的時(shí)候，命令處理任務(wù)處于阻塞態(tài)，此時(shí)，RTEMS系統(tǒng)正常運(yùn)行。當(dāng)被調(diào)試任務(wù)遇到斷點(diǎn)的時(shí)候，被調(diào)試任務(wù)阻塞在對(duì)Debu—gEvent信號(hào)量的P操作上，GDB得到被調(diào)試任務(wù)狀態(tài)變化的通知，用戶開(kāi)始下達(dá)調(diào)試命令。 GDB通過(guò)RSP傳送給被調(diào)試端的每一條命令，都會(huì)將命令處理任務(wù)喚醒。命令處理位務(wù)迅速執(zhí)行命令，將執(zhí)行結(jié)果回復(fù)，然后重新進(jìn)入到阻塞狀態(tài)，等待下一條命令的到來(lái)。如果收到被調(diào)試任務(wù)繼續(xù)執(zhí)行的命令，命令處理任務(wù)對(duì)DebugEvent信號(hào)量進(jìn)行V操作，使被調(diào)試任務(wù)得以繼續(xù)被調(diào)度。

4．3 其他相關(guān)問(wèn)題

第一個(gè)斷點(diǎn)：為了不讓被調(diào)試任務(wù)一下子運(yùn)行到結(jié)尾（不給調(diào)試服務(wù)任何的執(zhí)行機(jī)會(huì)），需要在被調(diào)試任務(wù)的開(kāi)頭以手工修改代碼的方式加入第一個(gè)斷點(diǎn)。斷點(diǎn)往往就是一個(gè)指定的軟中斷匯編指令（以i386為例，軟中斷對(duì)應(yīng)匯編指令“int 3”）。此時(shí)，用戶可以通過(guò)GDB遠(yuǎn)程下達(dá)調(diào)試命令，對(duì)被調(diào)程序進(jìn)行正常調(diào)試，并設(shè)置后繼的斷點(diǎn)?？烧{(diào)試代碼范圍：首先，調(diào)試服務(wù)中用到的代碼都是不可以被設(shè)置斷點(diǎn)的，這樣會(huì)引起調(diào)試服務(wù)的遞歸調(diào)用，系統(tǒng)會(huì)直接崩潰。其次，要避免在多個(gè)任務(wù)重入的代碼中設(shè)置斷點(diǎn)，這樣有可能多個(gè)任務(wù)向GDB匯報(bào)遇到了斷點(diǎn)，產(chǎn)生混亂。

結(jié)語(yǔ)

本文對(duì)RTEMS操作系統(tǒng)的調(diào)試手段進(jìn)行了探討。其中STUB調(diào)試方式比較成熟，可以參考GDB源碼中的．／gdb／i386一stub．c來(lái)理解 STUB的工作方式。在此基礎(chǔ)上，本文提出了面向任務(wù)的調(diào)試方式，在思路上延續(xù)STUB的路線，將調(diào)試服務(wù)分散到RTEMS任務(wù)和RTEMS軟中斷服務(wù)中去，實(shí)現(xiàn)了簡(jiǎn)單實(shí)用的面向任務(wù)的RTEMS調(diào)試手段。

責(zé)任編輯：gt