談談嵌入式操作系統的調試問題

　　談談嵌入式操作系統的調試問題   軟件測試

　　調試是開發過程中必不可少的環節，通用的桌面操作系統與嵌入式操作系統在調試環境上存在明顯的差別。前者，調試器與被調試的程序往往是運行在同一臺機器、相同的操作系統上的兩個進程，調試器進程通過操作系統專門提供的調用接口(早期UNIX系統的ptrace調用、如今的進程文件系統等)控制、訪問被調試進程。后者(又稱為遠程調試)，為了向系統開發人員提供靈活、方便的調試界面，調試器還是運行于通用桌面操作系統的應用程序，被調試的程序則運行于基于特定硬件平臺的嵌入式操作系統(目標操作系統)。這就帶來以下問題：調試器與被調試程序如何通信，被調試程序產生異常如何及時通知調試器，調試器如何控制、訪問被調試程序，調試器如何識別有關被調試程序的多任務信息并控制某一特定任務，調試器如何處理某些與目標硬件平臺相關的信息(如目標平臺的寄存器信息、機器代碼的反匯編等)。

　　我們介紹兩種遠程調試的方案，看它們怎樣解決這些問題。

　　調試方案

　　一 插樁(stub)

　　第一種方案是在目標操作系統和調試器內分別加入某些功能模塊，二者互通信息來進行調試。上述問題可通過以下途徑解決：

　　調試器與被調試程序的通信

　　調試器與目標操作系統通過指定通信端口(串口、網卡、并口)遵循遠程調試協議進行通信(遠程調試協議詳見http://rtos.ict.ac.cn/rtos/debugger/)。

　　被調試程序產生異常及時通知調試器

　　目標操作系統的所有異常處理最終都要轉向通信模塊，告知調試器當前的異常號;調試器據此向用戶顯示被調試程序產生了哪一類異常。

　　調試器控制、訪問被調試程序

　　調試器的這類請求實際上都將轉換成對被調試程序的地址空間或目標平臺的某些寄存器的訪問，目標操作系統接收到這樣的請求可以直接處理。對于沒有虛擬存儲概念的簡單的嵌入式操作系統而言，完成這些任務十分容易。

　　調試器識別有關被調試程序的多任務信息并控制某一特定任務

　　由目標操作系統提供相關接口。目標系統根據調試器發送的關于多任務的請求，調用該接口提供相應信息或針對某一特定任務進行控制，并返回信息給調試器。

　　調試器處理與目標硬件平臺相關的信息

　　第2條所述調試器應能根據異常號識別目標平臺產生異常的類型也屬于這一范疇，這類工作完全可以由調試器獨立完成。支持多種目標平臺正是GNU GDB的一大特色。

　　綜上所述，這一方案需要目標操作系統提供支持遠程調試協議的通信模塊(包括簡單的設備驅動)和多任務調試接口，并改寫異常處理的有關部分。另外目標操作系統還需要定義一個設置斷點的函數;因為有的硬件平臺提供能產生特定調試陷阱異常(debug trap)的斷點指令以支持調試(如X86的INT 3)，而另一些機器沒有類似的指令，就用任意一條不能被解釋執行的非法(保留)指令代替。目標操作系統添加的這些模塊統稱為"插樁"(見下圖)，駐留于ROM中則稱為ROM monitor。通用操作系統也有具備這類模塊的：編譯運行于Alpha、Sparc或PowerPC平臺的LINUX內核時若將kgdb開關打開，就相當于加入了插樁。

原文轉自：http://www.kjueaiud.com