嵌入式linux系統(tǒng)設計與應用 課件 第七章 嵌入式Linux系統(tǒng)移植

第七章嵌入式Linux系統(tǒng)移植目錄7.1BootLoader基本概念與典型結構7.2U-Boot7.3交叉開發(fā)環(huán)境的建立7.4交叉編譯工具鏈7.5嵌入式Linux系統(tǒng)移植過程7.6Gdb調試器7.7遠程調試7.8內核調試第七章嵌入式Linux系統(tǒng)移植（1）BootLoader基本概念與操作模式/常見的BootLoader/U-Boot

（2）交叉開發(fā)環(huán)境交叉開發(fā)環(huán)境的建立/交叉編譯工具鏈/clang與LLVM（3）嵌入式Linux系統(tǒng)移植U-Boot的移植/內核配置、編譯和移植BootLoader基本概念

一個嵌入式Linux系統(tǒng)通?？梢苑譃橐韵聨讉€部分：（1）引導加載程序及其環(huán)境參數。這里通常是指BootLoader以及相關環(huán)境參數。（2）Linux內核?；谔囟ㄇ度胧介_發(fā)板的定制內核以及內核的相關啟動參數。（3）文件系統(tǒng)。主要包括根文件系統(tǒng)和一般建立于Flash內存設備之上文件系統(tǒng)。（4）用戶應用程序?；谟脩舻膽贸绦颉Ｓ袝r在用戶應用程序和內核層之間可能還會包括一個嵌入式圖形用戶界面程序（GUI）。常見的嵌入式GUI有QT和MiniGUI等。在嵌入式操作系統(tǒng)中，BootLoader是在操作系統(tǒng)內核運行之前運行的一小段程序，可以初始化硬件設備、建立內存空間映射圖，從而將系統(tǒng)的軟硬件環(huán)境帶到一個適合的狀態(tài)，以便為最終調用操作系統(tǒng)內核準備好正確的環(huán)境。在嵌入式系統(tǒng)中，通常并沒有像通用計算機中BIOS那樣的固件程序，因此整個系統(tǒng)的加載啟動任務就完全由BootLoader來完成。BootLoader是嵌入式系統(tǒng)在加電后執(zhí)行的第一段代碼，在它完成CPU和相關硬件的初始化之后，再將操作系統(tǒng)映像或固化的嵌入式應用程序裝載到內存中然后跳轉到操作系統(tǒng)所在的空間，啟動操作系統(tǒng)運行。對于嵌入式系統(tǒng)而言，BootLoader是基于特定硬件平臺來實現的。因此，幾乎不可能為所有的嵌入式系統(tǒng)建立一個通用的BootLoader，不同的處理器架構都有不同的BootLoader。BootLoader不僅依賴于CPU的體系結構，而且依賴于嵌入式系統(tǒng)板級設備的相關配置。7.1.2BootLoader的操作模式大多數BootLoader都包含兩種不同的操作模式：自啟動模式和交互模式。這種劃分僅僅對于開發(fā)人員才有意義。（1）自啟動模式自啟動模式也叫啟動加載模式。在這種模式下，BootLoader自動從目標機上的某個固態(tài)存儲設備上將操作系統(tǒng)加載到RAM中運行，整個過程并沒有用戶的介入。這種模式是BootLoader的正常工作模式（2）交互模式交互模式也叫下載模式。在這種模式下，目標機上的BootLoader將通過串口或網絡等通信手段從開發(fā)主機上下載內核映像、根文件系統(tǒng)到RAM中。然后再被BootLoader寫到目標機上的固態(tài)存儲媒質（如FLASH）中，或者直接進入系統(tǒng)的引導。交互模式也可以通過接口（如串口）接收用戶的命令。這種模式在初次固化內核、根文件系統(tǒng)時或者更新內核及根文件系統(tǒng)時都會用到。7.1.3BootLoader的典型結構BootLoader啟動大多數都分為兩個階段。第一階段主要包含依賴于CPU的體系結構硬件初始化的代碼，通常都用匯編語言來實現。這個階段的任務有：基本的硬件設備初始化（屏蔽所有的中斷、關閉處理器內部指令/數據Cache等）。為第二階段準備RAM空間。如果是從某個固態(tài)存儲媒質中，則復制BootLoader的第二階段代碼到RAM。設置堆棧。跳轉到第二階段的C程序入口點。第二階段通常用C語言完成，以便實現更復雜的功能，也使程序有更好的可讀性和可移植性。這個階段的任務有：初始化本階段要使用到的硬件設備。檢測系統(tǒng)內存映射。將內核映像和根文件系統(tǒng)映像從Flash讀到RAM。為內核設置啟動參數。調用內核。ARM:S5PV210的啟動流程S5PV210的啟動過程由BL0、BL1和BL2（BL為BootLoader的簡稱）3部分代碼實現，其中BL0在出廠時已經被固化到64KB的iROM中。RISC-V基于SiFive的JH7100核嵌入式Linux啟動流程常見的BootLoader

（1）RedbootRedboot(RedHatEmbeddedDebugandBootstrap)是RedHat公司開發(fā)的一個獨立運行在嵌入式系統(tǒng)上的BootLoader程序，是目前比較流行的一個功能、可移植性好的BootLoader。Redboot是一個采用eCos開發(fā)環(huán)境開發(fā)的應用程序，并采用了eCos的硬件抽象層作為基礎，但它完全可以擺脫eCos環(huán)境運行，可以用來引導任何其他的嵌入式操作系統(tǒng)，如Linux、WindowsCE等。Redboot支持的處理器構架有ARM，MIPS，MN10300，PowerPC，RenesasSHx，v850，x86等，是一個完善的嵌入式系統(tǒng)BootLoader。（2）U-BootU-Boot（UniversalBootLoader）于2002年12月17日發(fā)布第一個版本U-Boot-0.2.0。U-Boot自發(fā)布以后已更新多次，其支持具有持續(xù)性。U-Boot是在GPL下資源代碼最完整的一個通用BootLoader。（3）BlobBlob(BootLoaderObject)是由Jan-DerkBakker和ErikMouw發(fā)布的，是專門為StrongARM構架下的LART設計的BootLoader。Blob的最后版本是blob-2.0.5。Blob功能比較齊全，代碼較少，比較適合做修改移植，用來引導Liunx，目前大部分S3C44B0板都用Blob修改移植后加載uClinux。（4）vivivivi是韓國mizi公司開發(fā)的BootLoader,適用于ARM9處理器，現在已經停止開發(fā)了。它是三星官方板SMDK2410采用的BootLoader。Vivi最主要的特點就是代碼小巧，有利于移植新的處理器。同時vivi的軟件架構和配置方法類似Linux風格，對于有過編譯Linux內核經驗的用戶，vivi更容易上手。

U-BootPartTwo7.27.2.1U-Boot概述U-Boot，全稱UniversalBootLoader，是遵循GPL條款的開放源碼項目。從FADSROM、8xxROM、PPCBOOT逐步發(fā)展演化而來。其源碼目錄、編譯形式與Linux內核很相似，事實上，不少U-Boot源碼就是根據相應的Linux內核源程序進行簡化而形成的，尤其是一些設備的驅動程序。

U-Boot支持多種嵌入式操作系統(tǒng)，主要有OpenBSD,NetBSD,FreeBSD,4.4BSD,Linux,SVR4,Esix,Solaris,Irix,SCO,Dell,NCR,VxWorks,LynxOS,pSOS,QNX,RTEMS,ARTOS,android等。同時，U-Boot除了支持PowerPC系列的處理器外，還能支持MIPS、x86、ARM、NIOS、XScale等諸多常用系列的處理器。U-Boot的主要特點有：源碼開放，目前有些版本的未開源。支持多種嵌入式操作系統(tǒng)內核和處理器架構。可靠性和穩(wěn)定性均較好。功能設置高度靈活，適合調試、產品發(fā)布等；設備驅動源碼十分豐富，支持絕大多數常見硬件外設；并將對于與硬件平臺相關的代碼定義成宏并保留在配置文件中，開發(fā)者往往只需要修改這些宏的值就能成功使用這些硬件資源，簡化了移植工作。U-Boot

arch/cpu目錄包含了特定cpu代碼，而board目錄則包含了特定目標板的代碼。因此主要的工作就可以集中在board相關的代碼，只要不是太新的cpu型號，因此可以直接復用這部分實現，選擇正確的配置選項。在U-Boot的這些源文件中，以S5PV210為例幾個比較重要的源文件如下所示：（1）start.S(arch\arm\cpu\armv7\start.S)通常情況下start.S是U-Boot上電后執(zhí)行的第一個源文件。該匯編文件包括定義了異常向量入口、相關的全局變量、禁用L2緩存、關閉MMU等，之后跳轉到lowlevel_init()函數中繼續(xù)執(zhí)行。（2）lowlevel_init.S(board\samsung\smdkv210\lowlevel_init.S)該源文件用匯編代碼編寫，其中只定義了一個函數lowlevel_init()。該函數實現對平臺硬件資源的一系列初始化過程，包括關看門狗、初始化系統(tǒng)時鐘、內存和串口。（3）board.c(arch\arm\lib\board.c)Board.c主要實現了U-Boot第二階段啟動過程，包括初始化環(huán)境變量、串口控制臺、Flash和打印調試信息等，最后調用main_loop()函數。（4）smdkv210.h(include\configs\Smdkv210.h)該文件與具體平臺相關，比如這里就是S5PV210平臺的配置文件，該源文件采用宏定義了一些與CPU或者外設相關的參數。U-Boot中的重要源文件（1）start.S(arch\arm\cpu\armv7\start.S)（2）lowlevel_init.S(board\samsung\smdkv210\lowlevel_init.S)（3）board.c(arch\arm\lib\board.c)（4）smdkv210.h(include\configs\Smdkv210.h)U-BOOT源碼分析及編譯

參考板的編譯makeARCH=armCROSS_COMPILE=arm-linux-distcleanmakeARCH=armCORSS_COMPILE=arm-linux-s5pc210_universal_defconfigmakeV=1ARCH=armCROSS_COMPILE=arm-linux--j1U-Boot啟動的一般流程

U-Boot啟動第一階段的主要工作U-Boot啟動的一般流程：第二階段（1）board_init_f()（2）board_init_r()7.2.3U-Boot環(huán)境變量U-Boot的環(huán)境變量是使用U-Boot的關鍵，它可以由用戶定義并遵守約定俗成的一些用法，也有部分是U-Boot定義并不得更改。值得注意的是在未初始化的開發(fā)板中并不存在環(huán)境變量。U-Boot在缺省的情況下會存在一些基本的環(huán)境變量，當用戶執(zhí)行了saveenv命令之后，環(huán)境變量會第一次保存到flash中，之后用戶對環(huán)境變量的修改和保存都是基于保存在flash中的環(huán)境變量的操作。環(huán)境變量名稱相關描述bootdelay

執(zhí)行自動啟動的等候秒數baudrate

串口控制臺的波特率netmask

以太網接口的掩碼ethaddr

以太網卡的網卡物理地址bootfile

缺省的下載文件bootargs

傳遞給內核的啟動參數bootcmd

自動啟動時執(zhí)行的命令serverip

服務器端的ip地址ipaddr

本地ip地址stdin

標準輸入設備stdout

標準輸出設備stderr

標準出錯設備表7-3U-Boot常用環(huán)境變量U-Boot的環(huán)境變量中最重要的兩個變量是：

bootcmd和bootargs。Bootcmd是自動啟動時默認執(zhí)行的一些命令，因此用戶可以在當前環(huán)境中定義各種不同配置，不同環(huán)境的參數設置，然后通過bootcmd配置好參數。

Bootargs是環(huán)境變量中的重中之重.7.2.4U-Boot命令U-Boot上電啟動后，按任意鍵退出自啟動狀態(tài)，進入命令行狀態(tài)。在提示符下，可以輸入U-Boot特有的命令完成相應的功能。U-Boot提供了更加周詳的命令幫助，通過help命令不僅可以得到當前U-Boot的所有命令列表，還能夠查看每個命令的參數說明。RISC-V架構的U-Boot引導過程M模式U-Boot引導過程

S模式U-Boot引導過程當在M模式U-Boot中運行時，它會加載包含固件和S模式操作系統(tǒng)的payload鏡像（例如fw_payload），在這種情況下，開發(fā)者可以使用mkimage將payload鏡像打包成uImage格式，并使用bootm命令啟動它。RISC-V生成啟動映像可能包含用于特定平臺初始化的U-BootSPL（SecondaryProgramLoader，第二階段程序加載器，也叫輔助程序加載器）。U-BootSPL然后加載一個FIT映像(u-boot.itb)，該鏡像包含提供SBI的固件（例如fw_dynamic），以及在S模式下運行的常規(guī)U-Boot（或U-Boot本身）.最后，加載S模式操作系統(tǒng)。7.3交叉開發(fā)環(huán)境的建立PartThree7.3交叉開發(fā)環(huán)境的建立主機-目標機交叉開發(fā)環(huán)境模式是由開發(fā)主機和目標機兩套計算機系統(tǒng)內組成的。開發(fā)主機一般指通用計算機，如PC等，目標機指嵌入式開發(fā)板（系統(tǒng)）。通過交叉開發(fā)環(huán)境，在主機上使用開發(fā)工具（如各種SDK），針對目標機設計應用系統(tǒng)進行設計工作，然后下載到目標機上運行。交叉開發(fā)模式一般采用以下3個步驟：（1）在主機上編譯BootLoader(引導加載程序)，然后通過JTAG接口燒寫到目標板。（2）在主機上編譯Linux內核，然后通過BootLoader下載到目標板以啟動或燒寫到Flash。（3）在主機上編譯各類應用程序，通過NFS運行、調試這些程序，驗證無誤后再將制作好的文件系統(tǒng)映像燒寫到目標板7.3.1.主機與目標機的連接方式主機與目標機的連接方式主要有串口、以太網接口、USB接口、JTAG接口等方式連接。主機可以使用minicom、kermit或者Windows超級終端等工具，通過串口發(fā)送文件。目標機亦可以把程序運行結果通過串口返回并顯示。以太網接口方式使用簡單，配置靈活，支持廣泛，傳輸速率快，缺點是網絡驅動的實現比較復雜。JTAG（JointTestActionGroup，聯合測試行動小組）是一種國際標準測試協(xié)議（IEEE1149.1標準），主要是用于對目標機系統(tǒng)中的各芯片的簡單調試，和對BootLoader的下載兩個功能。JTAG連接器中，其芯片內部封裝了專門的測試電路TAP（TestAccessPort,測試訪問口)，通過專用的JTAG測試工具對內部節(jié)點進行測試。因而該方式是開發(fā)調試嵌入式系統(tǒng)的一種簡潔高效的手段。JTAG有兩種標準，14針接口和20針接口。JTAG接口一端與PC機并口相連，另一端是面向用戶的JTAG測試接口，通過本身具有的邊界掃描功能便可以對芯片進行測試，從而達到處理器的啟動和停滯、軟件斷點、單步執(zhí)行和修改寄存器等功能的調試目的。其內部主要是由JTAG狀態(tài)機和JTAG掃描鏈的組成。雖然JTAG調試不占用系統(tǒng)資源，能夠調試沒有外部總線的芯片，代價也非常小，但是JTAG只能提供一種靜態(tài)的調試方式，不能提供處理器實時運行時的信息。它是通過串行方式依次傳遞數據的，所以傳送信息速度比較慢。7.3.2.主機-目標機的文件傳輸方式主機-目標機的文件傳輸方式主要有串口傳輸方式、網絡傳輸方式、USB接口傳輸方式、JTAG接口傳輸方式、移動存儲設備方式。串口傳輸協(xié)議常見的有kermit、Xmodem、Ymoderm、Zmoderm等。串口驅動程序的實現相對簡單，但是速度慢，不適合較大文件的傳輸。USB接口方式通常將主機設為主設備端，目標機設為從設備端。與其他通信接口相比，USB接口方式速度快，配置靈活，易于使用。如果目標機上有移動存儲介質如U盤等，可以制作啟動盤或者復制到目標機上，從而引導啟動。網絡傳輸方式一般采用TFTP（trivialfiletransportprotocol）協(xié)議。TFTP是一個傳輸文件的簡單協(xié)議，是TCP/IP協(xié)議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協(xié)議，提供不復雜、開銷不大的文件傳輸服務。端口號為69。此協(xié)議只能從文件服務器上獲得或寫入文件，不能列出目錄，不進行認證，它傳輸8位數據。傳輸中有三種模式：netascii，這是8位的ASCII碼形式；另一種是octet，這是8位源數據類型；最后一種mail已經不再支持，它將返回的數據直接返回給用戶而不是保存為文件。7.3.3.文件系統(tǒng)的掛接-配置網絡文件系統(tǒng)NFSNFS（NetworkFileSystem）即網絡文件系統(tǒng)，是FreeBSD支持的文件系統(tǒng)中的一種，它允許網絡中的計算機之間通過TCP/IP網絡共享資源。在NFS的應用中，本地NFS的客戶端應用可以透明地讀寫位于遠端NFS服務器上的文件，就像訪問本地文件一樣。NFS的優(yōu)點主要有：（1）節(jié)省本地存儲空間，將常用的數據存放在一臺NFS服務器上且可以通過網絡訪問，那么本地終端將可以減少自身存儲空間的使用。（2）用戶不需要在網絡中的每個機器上都建有Home目錄，Home目錄可以放在NFS服務器上且可以在網絡上被訪問使用。（3）一些存儲設備如軟驅、CDROM和Zip等都可以在網絡上被別的機器使用。這可以減少整個網絡上可移動介質設備的數量。交叉編譯工具鏈

交叉開發(fā)工具鏈就是為了編譯、鏈接、處理和調試跨平臺體系結構的程序代碼。從工具鏈的組成上來說，它一般由多個程序構成，glibc、gcc、binutils和gdb四個軟件提供分別對應著各個功能。常見的交叉編譯例子如下：（1）在WindowsPC上，利用諸如類似ADS、RVDS等軟件，使用armcc編譯器，則可編譯出針對ARMCPU的可執(zhí)行代碼。（2）在LinuxPC上，利用arm-linux-gcc編譯器，可編譯出針對LinuxARM平臺的可執(zhí)行代碼。（3）在WindowsPC上，利用cygwin環(huán)境，運行arm-elf-gcc編譯器，可編譯出針對ARMCPU的可執(zhí)行代碼。7.4.2工具鏈的構建方法通常構建交叉工具鏈有如下三種方法。方法一：分步編譯和安裝交叉編譯工具鏈所需要的庫和源代碼，最終生成交叉編譯工具鏈。該方法相對比較困難，適合想深入學習構建交叉工具鏈的讀者及用戶。如果只是想使用交叉工具鏈，建議使用下列的方法二構建交叉工具鏈。方法二：通過Crosstool腳本工具來實現一次編譯，生成交叉編譯工具鏈，該方法相對于方法一要簡單許多，并且出錯的機會也非常少，建議大多數情況下使用該方法構建交叉編譯工具鏈。方法三：直接通過網上下載已經制作好的交叉編譯工具鏈。該方法的優(yōu)點是簡單可靠，缺點也比較明顯，擴展性不足，對特定目標沒有針對性，而且也存在許多未知錯誤的可能，建議讀者慎用此方法。

GCC對于GUN編譯器來說，GCC的編譯要經歷四個相互關聯的步驟∶預處理(也稱預編譯，Preprocessing)、編譯(Compilation)、匯編(Assembly)和鏈接(Linking)。file.cc程序源文件file.ic程序預處理后文件file.cxxc++程序源文件，也可以是file.cc/file.cpp/file.c++file.iic++程序預處理后文件file.hc/c++頭文件file.s匯編程序文件file.o目標代碼文件Binutils與glibcBinutilsBinutils提供了一系列用來創(chuàng)建、管理和維護二進制目標文件的工具程序，如匯編（as）、連接（ld）、靜態(tài)庫歸檔（ar）、反匯編（objdump）、elf結構分析工具（readelf）、無效調試信息和符號的工具（strip）等。通常binutils與gcc是緊密相集成的，沒有binutils的話，gcc是不能正常工作的。

glibcGlibc是gnu發(fā)布的libc庫，也即c運行庫。Glibc是linux系統(tǒng)中最底層的應用程序開發(fā)接口，幾乎其它所有的運行庫都倚賴于glibc。Glibc除了封裝linux操作系統(tǒng)所提供的系統(tǒng)服務外，它本身也提供了許多其它一些必要功能服務的實現，比如open,malloc,printf等等。Glibc是GNU工具鏈的關鍵組件，用于和二進制工具和編譯器一起使用，為目標架構生成用戶空間應用程序。Makefile#makefileCC=arm-linux-gcc#指定交叉編譯器EXEC=hello$(EXEC):hello.c$(CC)hello.c–o$(EXEC)#注意命令需要用tab鍵Clean:Rm–f*.o$(EXEC)CC 指明編譯器的宏EXEC 表示生成的執(zhí)行文件名稱的宏OBJS 目標文件列表宏LDFLAGS 連接參數宏All： 編譯主入口Clean: 清除編譯結果Install： 將編譯成功的可執(zhí)行文件安裝到系統(tǒng)目錄中，一般為/usr/local/bin目錄擴展：clang與LLVMLLVM（LowLevelVirtualMachine，底層虛擬機)主要涉及到編譯器的中、后端,

其代碼以模塊的形式進行劃分和實現,

包括中間表示、代碼分析、優(yōu)化和代碼生成等。

clang主要涉及到編譯器的前端,

也是采用類似的形式進行模塊化實現,

包括抽象語法樹、詞法分析、語法分析、語義分析和LLVM中間代碼生成等.

LLVMLLVM編譯流程結構圖

高級語言前端結構圖

中間代碼優(yōu)化器結構圖

LLVM后端代碼生成器的結構圖GCC和Clang對比

嵌入式Linux系統(tǒng)移植過程PartFive7.5嵌入式Linux系統(tǒng)移植過程嵌入式Linux系統(tǒng)的移植主要有BootLoader（如U-Boot）、Linux內核、文件系統(tǒng)。嵌入式Linux系統(tǒng)移植的一般流程是：首先構建嵌入式Linux開發(fā)環(huán)境，包括硬件環(huán)境和軟件環(huán)境；其次，移植BootLoader；然后，移植Linux內核和構建根文件系統(tǒng)；最后，一般還要移植或開發(fā)設備驅動程序。U-Boot移植1.下載U-Boot源碼2.修改相應的文件代碼移植過程最主要的就是代碼的修改與文件的配置。國內嵌入式廠商研發(fā)的S5PV210開發(fā)板大都基于SMDKV210評估板做了減法和調整，所以三星提供的U-Boot、內核、文件系統(tǒng)大都適用于這些S5PV210開發(fā)板，因而在開發(fā)者在此基礎上只需要根據相應的makefile文件修改配置即可。U-Boot移植3.編譯U-BootU-Boot的編譯命令主要分兩步進行。第一步是配置，如makesmdkv210_config；第二步是編譯，執(zhí)行make就可以了。中。4.燒寫到開發(fā)板上，運行和調試新開發(fā)的板子沒有任何程序可以執(zhí)行，也不能啟動，需要先將U-Boot燒寫到flash或者SD卡Makefile體系Linux內核的配置

#makemenuconfigARCH=armCROSS_COMPILE=arm-linux-這個過程就稱為“配置內核”內核配置的基本原則是把不必要的功能都去掉，不僅可以減小內核大小，還可以節(jié)省編譯內核和內核模塊的時間。內核移植對于內核移植而言，主要是添加開發(fā)板初始化和驅動程序的代碼，這些代碼大部分是跟體系結構相關。具體到cotrex-A8型開發(fā)板來說，linux已經有了較好的支持。比如從Kernel官方維護網站

上下載到2.6.35的源代碼，解壓后查看arch/arm/目錄下已經包含了三星S5PV210的支持，即三星官方評估開發(fā)板SMDK210的相關文件mach-smdkv210了。移植Kernel只需要修改兩個開發(fā)板之間的差別之處就可以了。具體例子可以見書7.5.2節(jié)。

內核配置與編譯Gdb調試器PartSix7.6GDB（GNUDeBugger）是自由軟件基金會（FreeSoftwareFoundation，FSF）的軟件工具之一。它的作用是協(xié)助程序員找到代碼中的錯誤。（1）進入GDB

Gdbtesttest是要調試的程序，由gcctest.c-g-otest生成。進入后提示符變?yōu)?Gdb)。（2）查看源碼(Gdb)l源碼會進行行號提示。如果需要查看在其他文件中定義的函數，在l后加上函數名即可定位到這個函數的定義及查看附近的其他源碼?；蛘撸菏褂脭帱c或單步運行，到某個函數處使用s進入這個函數。（3）設置斷點(Gdb)b6這樣會在運行到源碼第6行時停止，可以查看變量的值、堆棧情況等；這個行號是Gdb的行號。（4）查看斷點處情況(Gdb)

infob可以鍵入"infob"來查看斷點處情況，可以設置多個斷點；（5）運行代碼(Gdb)

r（6）顯示變量值(Gdb)

pn在程序暫停時，鍵入"p變量名"(print)即可；GDB在顯示變量值時都會在對應值之前加上"$N"標記，它是當前變量值的引用標記，以后若想再次引用此變量，就可以直接寫作"$N"，而無需寫冗長的變量名；（7）觀察變量(Gdb)

watchn在某一循環(huán)處，往往希望能夠觀察一個變量的變化情況，這時就可以鍵入命令"watch"來觀察變量的變化情況，GDB在"n"設置了觀察點；（8）單步運行(Gdb)

n（9）程序繼續(xù)運行(Gdb)

c使程序繼續(xù)往下運行，直到再次遇到斷點或程序結束；（10）退出GDB

(Gdb)

q

Gdb中，輸入命令時，可以不用打全命令，只用打命令的前幾個字符就可以了，當然，命令的前幾個字符應該要標志著一個唯一的命令，在Linux下，可以敲擊兩次TAB鍵來補齊命令的全稱，如果有重復的，那么Gdb會把其例出來。遠程調試PartSix7.7在嵌入式軟件調試過程中，調試器通常運行于主機環(huán)境中，被調試的軟件則運行于基于特定硬件平臺的目標機上。主機上的調試器通過串口、并口或網卡接口等通信方式與目標機進行通信，控制目標機上程序的運行，實現對目標程序的調試，這種調試方式稱為遠程調試。常用的遠程調試技術主要有插樁(stub)和片上調試（OnChipDebugging，OCD）兩種。插樁(stub)指在目標操作系統(tǒng)和調試器內分別加入某些軟件模塊實現調試；片上調試指在微處理器芯片內嵌入額外的控制電路實現對目標程序的調試。片上調試方式不占用目標平臺的通信端口，但它依賴于硬件。插樁方式僅需要一個用于通信的端口，其他全部由軟件實現。7.7.1遠程調試工具的構成插樁方式下的調試環(huán)境構成遠程調試工具由三部分構成：主機端的調試器、遠程通信協(xié)議和插樁模塊。前兩部分可采用GDB（GNUdebugger）調試器來解決。為了監(jiān)控和調試程序,主機GDB通過串行協(xié)議使用內存讀寫命令，無損害地將目標程序原指令用一個trap指令代替，從而完成斷點設置動作。7.7.2通信協(xié)議-RSP$<data>#[chksum]該數據包分為四部分：第一部分是包頭，由字符“$”構成；第二部分是數據包內容，對應調試信息，它可以是調試器發(fā)布的命令串，也可以是目標機的應答信息，數據包中應該至少有一個字節(jié)；第三部分是字符“#”，它是調試信息的結束標志；

第四部分是由兩位十六進制數的ASCII碼字符構成的校驗碼，7.7.3遠程調試的實現方法及設置相對于宿主機遠程調試環(huán)境的建立過程，目標機調試stub的實現更要復雜，它要提供一系列實現與主機GDB的通信和對被調試程序的控制功能的函數。這些功能函數GDB有的已經提供,如Gdb文件包中的m68k-stub.c、i386-stub.c等文件提供了一些相應目標平臺的stub子函數，有的函數需要開發(fā)者根據特定目標平臺自行設計實現。stub的主要子函數：sets_debug_traps()：函數指針初始化，捕捉調試中斷進入handle.exception（）函數。Handle_exception()：該函數是stub的核心部分。程序運行被中斷時，首先發(fā)送一些主機的狀態(tài)信息，如寄存器的值，然后在主機Gdb的控制下執(zhí)行程序，并檢索和發(fā)送Gdb需要的數據信息，直到主機Gdb要求程序繼續(xù)運行，handle_exception（）交還控制權給程序。Breakpoint（）：該功能函數可以被調試程序中設置斷點。除以上函數外,開發(fā)人員需要針對特定目標平臺，為stub實現以下底層功能函數，才能使調試stub正常與主機GDB協(xié)同工作，比如：GetDebugChar（）、putDebugChar（）：讀寫通過Gdb遠程串行協(xié)議與主機交互的數據。ExceptionHandler（）：各目標平臺對系統(tǒng)中斷向量的組織安排是不一樣的，該函數要能夠使得系統(tǒng)中斷發(fā)生時，程序可以正常獲得中斷服務程序的入口地址。Memset（）：標準庫函數，保證對特定目標平臺的內存操作。開發(fā)者就可以按以下步驟使用stub對目標程序進行遠程調試：（1）在被調試程序開始處，插入兩個函數調用:sets_debug_traps()和handle.exception()。（2）將被調試程序、GDB提供的stub功能函數和上述目標系統(tǒng)中實現的stub底層子函數一起編譯鏈接生成一個包含調試stub的目標程序。（3）建立主機與目標機的串口或以太口連接，保證通信物理鏈路的順暢。（4）將被調試目標代碼下載到目標系統(tǒng)并運行該程序，它會被內部stub函數中斷在開始處，等待宿主機GDB的連接請求。（5）在宿主機運行針對目標平臺編譯鏈接Gdb。用targetremote命令連接目標機stub，然后就使用相應GDB命令對目標程序進行跟蹤和調試了。7.7.4遠程調試應用實例方法目前嵌入式linux系統(tǒng)中，主要有三種遠程調試方法，分別適合與不同場合的調試工作：用ROMMonitor調試內核裝載程序、用KGDB調試系統(tǒng)內核和用GDBserver調試用戶空間程序。這三種調試的方法的區(qū)別主要在于目標機遠程調試stub的存在形式不同，而設計思路和實現方法則大致相同，并且它們配合工作的主機Gdb是同一個程序。1.用ROMMonitor調試目標機程序在嵌入式linux內核運行前的狀態(tài)中，程序的裝載、運行和調試一般都由RomMon