使用GDB與QEMU除錯核心時的問題分析(轉)

使用GDB與QEMU除錯核心時的問題分析(轉)[@more@]　　使用QEMU+GDB能夠實現原始碼級的核心除錯，但是，存在一個問題──當核心允許中斷時，單步命令（n與s）會進入時鐘中斷。透過瀏覽QEMU的原始碼，大體把原因找了出來。 單步命令（n與s）在gdb遠端除錯通訊協議中是s（參看info gdb），qemu的gdb stub在受到s命令後將虛擬CPU進入單步狀態，但是在接收到s命令前，qemu的虛擬CPU是停止的（在等待gdb的命令），注意，這個時候，虛擬時鐘計時並沒有停止，所以，很可能在qemu的虛擬CPU還沒開始的時候就需要觸發時鐘中斷了，但是虛擬CPU還在停止狀態，中斷無法觸發。接收到s命令後，虛擬CPU開始執行指令。這時，如果核心允許中斷，虛擬時鐘就將觸發中斷，所以s命令執行一條指令後停止在時鐘中斷處理程式的開始處，而不是希望的函式中下一條指令處。

　　現在看一下問題的解決方法。在我看來，需要修改gdb遠端除錯核心時單步命令的語義。有兩個方向。

　　1.在gdb上修改。在處理使用者的n與s命令時不是傳送協議中的s命令，而是分兩步。首先確定下一條指令的開始位置（或者下一行源程式對應的指令的開始位置）。對於有些RISC機器機器指令固定為某個長度，那麼確定這個位置比較簡單，但是對於像x86這樣的變長指令的體系結構就需要稍微麻煩一點（需要確定當前指令的長度等）。然後假如第一步確定的地址是naddr。現在像處理使用者的tbreak *naddr一樣處理就可以了，接著傳送繼續執行命令c就可以了。

　　2.在qemu的gdb stub上修改協議命令s的處理方法。接收到s命令後不是讓虛擬CPU進入單步執行狀態，而是確定在沒有中斷的情況下，下一條指令的位置（注意對於當前是跳轉指令的情況處理比較複雜），然後在這個位置設定臨時斷點，在虛擬CPU到達這個斷點進入gdb stub後立即將其取消。

　　這兩種處理方法中，我認為1比較好，實現起來清晰明瞭，但是需要對gdb的程式碼比較熟悉。2方法比較複雜，尤其是在當前指令是跳轉指令時，不太容易確定臨時斷點的位置。另外作為暫時的權宜之計，我們可以只使用tbreak +offset來代替n與s命令。