1 RTEMS操作系統(tǒng)簡介
    RTEMS，即實時多處理器系統(tǒng)(Real Time Executivefor Multiprocessor Systems)，是一個開源的實時嵌入式操作系統(tǒng)。它最早用于美國國防系統(tǒng)，現在它在航空航天、軍工及民用領域都有著廣泛的應用。
    從結構上來看，RTEMS是微內核搶占式實時系統(tǒng)。圖1顯示了RTEMS操作系統(tǒng)的基本結構。圖中白色部分為RTEMS操作系統(tǒng)的硬件支持部分(Board SupportPackage)，它包括了硬件抽象代碼、硬件設備驅動代碼和操作系統(tǒng)啟動代碼?；疑糠譃镽TEMS內核以及系統(tǒng)提供給應用程序的API。在具體應用場景中，圖中所有系統(tǒng)模塊都被編譯成一個靜態(tài)連接庫，用戶編寫的應用程序和RTEMS庫靜態(tài)鏈接成一個整體，形成運行在目標環(huán)境的鏡像文件。應用程序只將需要的系統(tǒng)支持模塊鏈接進來，最大程度地縮小了可執(zhí)行鏡像的大小。

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

2 GDB遠程調試
    GDB全稱GNU symbolic debugger。在大多數情況下，在UNIx或者Linux環(huán)境下使用GDB調試本機程序，GDB通過waitpid、ptrace等系統(tǒng)調用對被調試進程進行監(jiān)查和控制。這種調試模式很常見，但它只是GDB調試的一種特殊情況：GDB本身的運行環(huán)境和被調試程序的運行環(huán)境恰巧是同一個。在有些情況下，被調試程序運行環(huán)境下可能無法方便地運行GDB，那么遠程調試就會派上用場。
2．1 遠程調試中程序的交互途徑
    如圖2所示，GDB和被調試程序運行于不同的環(huán)境中。在GDB加載了和被調試程序對應的調試信息之后，用戶可以通過它對被調程序進行源代碼級調試。用戶向GDB下達調試命令，GDB將用戶的調試命令翻譯、打包，通過串口或者網絡接口發(fā)送至被調試程序端的GDB—SERVER。GDB—SERVER將接收到的調試命令包解包，并將其表達的調試命令實施于被調試程序。如果需要，還應將命令執(zhí)行結果通過遠程通信返回給GDB端。

2．2 GDB與GDB—SERVER
    GDB和GDB—SERVER之間的數據通道上傳輸的信息遵循GDB Remote Serial Protocol。它是一種簡潔的、基于ASCII的協議。每一個RSP報文由ASCII符號“$”開頭，由“#”將報文內容和兩個字節(jié)的報文校驗隔開，如下所示：

    接收方對報文進行校驗，如果校驗成功，回復ASCII字符“+”，否則回復“一”。
    通過RSP傳輸的命令種類很多，比較常用的羅列于表1中。當用戶使用GDB遠程調試程序時，GDB將用戶的命令翻譯成若干條RSP命令的序列下達給GDB—SERVER。GDB—SERVER對命令進行實施，并回復運行結果。作為一個能實現基本調試功能的GDB—SERVER，至少需要實現表1中列出的命令。

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

3 傳統(tǒng)STUB調試模式概述
    GDB—STUB是嵌入在被調試程序中的小段程序，它肩負了和GDB通信并執(zhí)行GDB調試命令的重任?？梢哉fGDB—STUB是輕量級的GDB—SERVER。它代碼量很少，在RTEMS啟動初始化階段，將它以軟中斷處理程序的身份嵌入到RTEMS之中，成為RTEMS的一部分。當被調試程序運行到這個特殊的軟中斷時，STUB程序獲得運行的權力，和GDB進行遠程通信，執(zhí)行調試命令，直到收到被調試程序繼續(xù)執(zhí)行的命令，STUB恢復被調試程序的執(zhí)行，如圖3所示。

    由于它和被調試程序融為一體，所以它可以直接訪問被調試程序的內存地址，查詢或者修改被調試程序內存空間的值。
    此方法將RTEMS系統(tǒng)看作一個嵌入式裸板程序，可以在源碼級別對整個RTEMS系統(tǒng)進行調試?？梢韵胂?，此時GDB根本不知道被調試程序是一個操作系統(tǒng)，一旦STUB獲得了執(zhí)行機會，整個RTEMS系統(tǒng)進入暫停狀態(tài)，無論系統(tǒng)中運行的是應用還是系統(tǒng)內核本身。而調試系統(tǒng)本身遠遠沒有調試系統(tǒng)中應用程序的需求量大，在調試應用的時候，希望只是被調試的任務暫停，系統(tǒng)中其他任務不受我們調試行為的影響。下文將介紹RTEMS任務級別的GDB遠程調試方法。

[!--empirenews.page--]4 面向任務的RTEMS調試
    為了實現面向RTEMS任務的調試手段，將調試相關服務抽象成RTEMS任務和RTEMS中斷處理程序。這樣調試服務也將作為任務被RTEMS系統(tǒng)調度，當沒有調試需求的時候，這些任務處于不可調度狀態(tài)，不影響整個系統(tǒng)的運行。調試服務由以下三部分組成：
    初始化任務，負責整個RTEMS調試服務的啟動。
    命令處理任務，與GDB交互，執(zhí)行命令，并回復執(zhí)行結果。
    事件處理程序，獲取任務中斷信號，通知GDB被調試任務的狀態(tài)。
    這三部分的邏輯關系如圖4所示。

4．1 調試任務說明
    (1)初始化任務
    初始化任務負責整個RTEMS調試服務的啟動。它首先對GDB和調試服務之間的通信路徑(串口或者網絡接口)進行初始化，然后建立命令處理任務，并將事件處理程序與對應的軟中斷掛接起來。在初始化一切正常的情況下，初始化任務的歷史使命徹底完成，它將自己刪除。
    (2)命令處理任務
    命令處理任務由初始化任務建立。當GDB有命令到來的時候它被喚醒，接受命令，執(zhí)行命令，并將執(zhí)行結果發(fā)送回GDB。
    現在整個調試服務都建立在RTEMS任務機制之上，又由于RTEMS支持POSIX接口規(guī)范，在“執(zhí)行命令”階段使用ptrace之類的系統(tǒng)調用來控制被調試任務是更好的選擇。它可以降低調試服務和硬件平臺的關聯性，易于調試服務的移植和擴展。
    在GDB發(fā)送繼續(xù)執(zhí)行命令(c命令或者s命令)的時候，命令處理程序對全局信號量DebugEvent進行一次V操作，使被調試程序成為可調度任務。
    (3)事件處理程序
    事件處理程序不是一個任務，而是一個軟中斷處理程序。當被調試程序遇到斷點(軟中斷命令)的時候，處理器會轉到事件處理程序上來。在STUB調試模式中，基本所有調試功能都在這個程序中完成，這就阻礙了RTEMS系統(tǒng)以及系統(tǒng)中其他任務的運行。
    現在，事件處理程序只是報告GDB被調試程序中斷發(fā)生，然后將對全局信號量DebugEvent進行一次P操作，使被調試任務進入不可調度狀態(tài)。
    在此要注意軟中斷的性質，它不同于真正的外部中斷。用操作系統(tǒng)接口的概念來類比將更容易理解：當遇到一個軟中斷的時候，RTEMS將堆棧轉換成對應任務的系統(tǒng)堆棧，但是此時仍然處于任務上下文當中，那么當然也就可以在事件處理程序中睡眠。
4．2 調試任務同步關系
    通過任務優(yōu)先等級和信號量來維持調試系統(tǒng)任務之間的同步關系。
    首先，初始化任務和命令處理任務擁有相同的優(yōu)先級——RTEMS中最高的優(yōu)先級，其他所有應用的優(yōu)先級都要低于此優(yōu)先級，不能等于。這樣就保證了GDB送來調試命令的時候，命令處理任務能夠及時反應。
    其次，使用全局DebugEvent信號量來控制被調試任務的調度狀態(tài)。每次遇到斷點，被調試任務進入事件處理程序(可看作是一個系統(tǒng)調用陷入)中，阻塞在事件處理程序的P操作之上。當命令處理任務收到被調試任務繼續(xù)執(zhí)行的命令時，對DebtagEvent信號量進行V操作，使被調試任務重新可調度。
    最終調試服務的運行狀態(tài)是：初始化任務在系統(tǒng)運行之初就刪除了自己；在GDB不發(fā)送命令的時候，命令處理任務處于阻塞態(tài)，此時，RTEMS系統(tǒng)正常運行。當被調試任務遇到斷點的時候，被調試任務阻塞在對Debu—gEvent信號量的P操作上，GDB得到被調試任務狀態(tài)變化的通知，用戶開始下達調試命令。GDB通過RSP傳送給被調試端的每一條命令，都會將命令處理任務喚醒。命令處理位務迅速執(zhí)行命令，將執(zhí)行結果回復，然后重新進入到阻塞狀態(tài)，等待下一條命令的到來。如果收到被調試任務繼續(xù)執(zhí)行的命令，命令處理任務對DebugEvent信號量進行V操作，使被調試任務得以繼續(xù)被調度。
4．3 其他相關問題
    第一個斷點：為了不讓被調試任務一下子運行到結尾(不給調試服務任何的執(zhí)行機會)，需要在被調試任務的開頭以手工修改代碼的方式加入第一個斷點。斷點往往就是一個指定的軟中斷匯編指令(以i386為例，軟中斷對應匯編指令“int 3”)。此時，用戶可以通過GDB遠程下達調試命令，對被調程序進行正常調試，并設置后繼的斷點?？烧{試代碼范圍：首先，調試服務中用到的代碼都是不可以被設置斷點的，這樣會引起調試服務的遞歸調用，系統(tǒng)會直接崩潰。其次，要避免在多個任務重入的代碼中設置斷點，這樣有可能多個任務向GDB匯報遇到了斷點，產生混亂。

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