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

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