--- title: Lab27: Debugger toc: no ... 預期目標 ------- - 學習使用 Debugger，並且理解從硬體到軟體相關的處理機制 - 配合[第三周進度](/embedded/2014-w3)，學習 Linux 工具和 GNU Toolchain 的使用 - 學習 Automation 技巧 GDB ---- * http://www.slideshare.net/chenkaie/gdb-rocks-16951548 * http://descent-incoming.blogspot.tw/2013/04/for-stm32f4discovery-0-linux.html QEMU + GDB 操作 ---------------- - 假設 [Lab-25](/embedded/Lab25) 所使用 QEMU 的目錄已放在 workspace 目錄 .. code-block:: prettyprint cd workspace file qemu_stm32 - 取得 GDB Automation .. code-block:: prettyprint git clone git://github.com/embedded2014/rtenv-gdbautomation.git git clone git@github.com:embedded2014/rtenv-gdbautomation.git # 如果上一行失敗 cd rtenv-gdbautomation - 開啟一個終端機，作以下輸入 .. code-block:: prettyprint make qemudbg - 開啟另一個終端機，準備透過 gdb 來追蹤程式。下列 (gdb) 開頭的指令表示在 GDB 內部操作 - 使用 Ubuntu 64-bit 版本時，需要另外安裝 lib32ncurses5 - sudo apt-get install lib32ncurses5 .. code-block:: prettyprint cd rtenv-gdbautomation arm-none-eabi-gdb (gdb) file main.elf Reading symbols from rtenv-gdbautomation/main.elf...done. (gdb) b main Breakpoint 1 at 0x2206: file main.c, line 8. (gdb) target remote :3333 Remote debugging using :3333 Reset_Handler () at libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x/startup/gcc_ride7/startup_stm32f10x_md.s:67 67 movs r1, #0 (gdb) c Continuing. Breakpoint 1, main () at main.c:8 * ``make qemu`` 可作測試 Unit Test --------- - 「在以往我們常常不停地改寫程式，在這個過程中，有意無意地常常會有東西被改壞掉還不知道，而我們檢查的方式可能很常是透過一直修改程式碼或輸入的資料來測試 - 但是當程式越來越大，我們測試時只專注在一個地方，此時所要測試的程式越來越多，不小心出錯的可能也越來越多，每改寫一次就是一次昂貴的人力檢查，最後程式就像一艘漏水的船，補了這裡，那裡卻又多了一個洞，船員像無頭蒼蠅一樣四處補洞，這樣的情況就是 Unit Test 能解決的問題 - 透過Unit Test，每次寫的程式碼都交給程式自動測試，一來測試的速度很快，不管是一百次還是一千次，總比人工測試來得快速、正確、廣範，但這不是免費的，代價就是程式設計師要寫很多 Unit Test 的程式碼，還要想要如何寫 Unit Test 的程式 - 進一步的還有測試導向的開發模式(Test-driven development)，程式是在Unit Test寫完之後才開始寫，這樣一來迫使程式設計師在一開始就得把設計想好」 * http://blog.ez2learn.com/2009/01/21/try-google-unit-test-framework/ - http://www.dotblogs.com.tw/hatelove/archive/2012/05/08/unit-test-introduction.aspx - http://teddy-chen-tw.blogspot.tw/2011/11/unit-tests.html - Android CTS: http://source.android.com/compatibility/cts-intro.html GDB Automation --------------- * 目標：使用 GDB 來驗證 rtenv 功能，特別是新加入的 shell command * 取得 rtenv-gdbautomation 並編譯、執行驗證 .. code-block:: prettyprint git clone git@github.com:embedded2014/rtenv-gdbautomation.git git clone http://github.com/embedded2014/rtenv-gdbautomation.git # 如果上一行失敗 cd rtenv-gdbautomation make check * 可以看到如下方輸出 .. code-block:: prettyprint arm-none-eabi-gdb -batch -x test-export_envvar.in first () at kernel.c:791 791 while(1); Breakpoint 1 at 0x5b84: file unit_test.c, line 4. Current environment variables: Name: EDITOR; Value: gedit Name: PATH; Value: ~ Name: LC_ALL; Value: UTF8 Processed argv list: #0 export #1 EDITOR=vi Pass: exported value is correct Pass: correct value of env_count * 研究 test-export_envvar.in 檔案的設計，發現是 GDB script - source qemudbg_init.in # 可發現 GDB macro - set logging on 參考作業要求 ------------------ * 將 rtenv-gdbautomation 機制移植回去 [Lab-25](/embedded/Lab25) 的 rtenv，使得 ``make check`` 時，可以透過 GDB script 自動測試之前加入的功能、函式，並且比對預期輸出，作為 unit test * [加分] 用 GDB script 顯示執行時期資訊 作業繳交方式 ------------------ * 請更新作業提案到共筆網站: [Lab 27 / 作業共筆](https://embedded2014.hackpad.com/Lab-27-GDB-Automation-L1ohwuTnRMw) - 需要標注自己的 ID，可參考 [Lab 25 / 作業共筆](https://embedded2014.hackpad.com/Lab25-GNU-Toolchain-iqMI18AAgwU) 的格式 * 請在 Mar 14, 2014 前，將符合作業提案的程式碼，提交到 [Lab-25](/embedded/Lab25) 時 fork 出來的 rtenv - https://github.com/embedded2014/rtenv 參考資訊 ------- - debugger 和 software emulator * opencsl.openfoundry.org/Lab05_debugger.rst.html * http://www.cis.nctu.edu.tw/~is92004/article/gdb.htm - GDB 筆記 * http://loda.hala01.com/2012/04/gdb%E7%AD%86%E8%A8%98/ - 以 GDB 重新學習 C 語言程式設計 * http://www.slideshare.net/jserv/clang-usinggdb - GDB Manual * http://sourceware.org/gdb/current/onlinedocs/gdb/ * Commands, Remote Debugging, Extending GDB