RTEMS任務(wù)級(jí)別調(diào)試技術(shù)研究

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)變化的通知，用戶(hù)開(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í)，用戶(hù)可以通過(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的路線(xiàn)，將調(diào)試服務(wù)分散到RTEMS任務(wù)和RTEMS軟中斷服務(wù)中去，實(shí)現(xiàn)了簡(jiǎn)單實(shí)用的面向任務(wù)的RTEMS調(diào)試手段。