再聊 CPUState、qemu 的 gdbserver

jollen 發表於 April 18, 2007 12:06 AM

前一則日記「小聊 qemu 的 CPUState」提到:

相關應用,例如,我們只要觀察 r15(pc)暫存器的值,就可以知道現在這台機器的程式執行位置。實際上的應用,像是 qemu 所實作的 gdbserver 即是透過此 object 的資訊,來回覆 gdb client 的命令。

以下展示實際的操作畫面。

下圖是利用 jk2410-emulator 模擬 Jollen-Kit! Pro. 的開機畫面,使用的 kernel 是 2.6.20.4:

在 kernel 檢查 root filesystem 是否為 initramfs 的時候,我們啟動了 gdb client,並透過 socket 連到 qemu 的 gdbserver;為了方便進行 source-level debug,我們使用 cgdb 來操作,下圖是 debug 畫面:

我們可以看到,此時 kernel 正執行到 lib/inflate.c 裡的第 59x 行程式,我們利用 next 做單步執行。這種「一邊跑 kernel,一邊看 kernel 跑到哪一個原始檔的哪一行」正是使用 qemu 做「整體系統」除錯的關鍵突破之一。

回到 qemu,找到 gdbserver 的實作 'gdbstub.c';當 host 的 gdb(gdb client)端對 target 端 gdb server 下命令時(透過 gdb remote protocol),qemu 實作的 gdb server 會先由 CPUState 讀取 register 的內容,再回應給 gdb client。gdb remote debug protocol 顯然不是我們目前的重點,所以先找到 'gdbstub.c' 關於「讀取 ARM 處理器 register」的主要程式片斷如下:

#elif defined (TARGET_ARM)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
    int i;
    uint8_t *ptr;

    ptr = mem_buf;
    /* 16 core integer registers (4 bytes each).  */
    for (i = 0; i < 16; i++)
      {
        *(uint32_t *)ptr = tswapl(env->regs[i]);
        ptr += 4;
      }
    /* 8 FPA registers (12 bytes each), FPS (4 bytes).
       Not yet implemented.  */
    memset (ptr, 0, 8 * 12 + 4);
    ptr += 8 * 12 + 4;
    /* CPSR (4 bytes).  */
    *(uint32_t *)ptr = tswapl (cpsr_read(env));
    ptr += 4;

    return ptr - mem_buf;
}

gdb server 回傳給 host 端的資訊,已經由 host 端的 gdb 為我們解析,並根據 debug sections 來找到 $pc 對應的原始程式位置,即 source-level debug。

由於這種除錯模式,是對「整粒 ARM 處理器」做除錯,概念上很像是 jtag debug,因此會比用 kgdb 或 kdb 來得實用。原理上來看,gdb 單純是對 qemu 做除錯,而 qemu 是一個可以讓「完整 Linux 系統」在上面執行的 'system emulator'(for various processors),所以我們可以對模擬器裡頭的程式概念上「直接」進行除錯,因為對 host 端的 gdb 來說,這是通透的(transparent)。

再者,對除錯的二大重要工作:source-level debug 或是「單步執行」來說,qemu 單純只回應 $pc 給 gdb client,qemu 並不會知道現在跑的程式是什麼,同時也不需再加入(或修改)gdb stub 至 kernel 或 application,這樣的通透性,讓此種除錯模式可說是非常「萬能」的。不過,在實務上仍有一些不足的地方,例如,我們需要在 host 端編譯出具備除錯資訊的程式,才能搭配 qemu 來除錯,並且,也要小心注意 host 端的 loaded ELF image 與 run-time 的程式是否相同。

高通透性並非全然都是好的,例如,即使 loaded kernel image(vmlinux)與 run-time kernel 不同,我們還是會看到「目前跑到 source code 什麼地方」,因此目前的 source code 位置$pc 的位址是對不起來的。實務上,host gdb 透過 qemu 來除錯 kernel 的高度通透性,也帶來了一些小問題,有機會再做整理分享,或許可在 [OrzLab] 的讀書會上提出討論。

不過,如果是因為忘了重新打包 kernel,就直接跑 emulator 進行除錯,而發生上述的錯誤,實在是非戰之罪。

來源: Jollen's Blog

讀者留言 (0)

留言功能維護中。將於近日重新開放。

連絡作者

Jollen Chen,Moko365(仕橙3G教室)講師,熱愛研究 Linux 與 Android 技術。曾為 Motorola、HTC、Foxconn、LG、OPPO、騰迅、廣達電腦、緯創、仁寶等超過 50 家企業講授課程。目前在 MokoVersity 擔任軟體工程師,撰寫 Node.js 程式,也在幾家科技廠兼任 Android Framework 研發顧問。您可透過電子郵件 <jollen (at) jollen (dot) org> 或這裡與我連絡。