调试是开发过程中必不可少的环节，然而内核、嵌入式系统的调试不同于传统的调试系统。通常嵌入式系统不具备使用本地调试器" title="调试器">调试器的能力，原因如下：
　　(1)系统自身的资源有限，内存小，输入输出设备不能用于调试。
　　(2)传统的调试系统需要文件系统，而嵌入式系统通常无文件系统，内核调试时还不支持文件系统。
　　(3)调试器的运行本身需要操作系统的支持，因此无法实现操作系统内核的调试。
　　最有效的解决方法是采用远程调试技术。远程调试是指调试器运行的环境(主机)与被调试的系统(目标机)在物理上是分离的、通过串口或者网络进行连接的调试技术。
　　GNU免费提供的GDB拥有强大的远程调试功能，它能够使开发人员以远程调试的方式单步执行目标平台上的程序代码、设置断点、查看内存，并与目标平台交换信息。GDB远程调试的实时、动态、方便、免费等优点，使它逐渐成为嵌入式开发首选的调试方案。
　　远程调试系统由三部分组成：主机上的本地调试器、目标机上的调试代理、远程调试协议，如图1所示。对应GDB远程调试系统的三部分为：GDB、GDBstub、GDB远程串行协议。下面就这三部分进行分析。

1 RSP协议
　　GDB RSP(Remote Serial Protocol)定义了GDB宿主机与被调试目标机进行通信时数据包的格式。信息的格式是：＄数据#校验码。多数信息使用ASCII码，数据由一系列的ASCII码组成，校验码是由两个16进制数组成的单字节校验码。接收方接收数据并校验，若正确则回应“＋”，否则回应“－”。通信的内容包括读写数据、控制程序运行、报告程序状态等命令。RSP的基本命令从通信对话角度可以分为两种：
　　(1)请求
　　?：读当前系统状态
　　g：读所有寄存器
　　G〈register_data〉：写所有寄存器
　　m〈address〉，〈length〉：读内存
　　M〈address〉，〈length〉：〈memory_data〉：写内存
　　c：继续执行
　　s：单步执行
　　k：终止进程
　　(2)答复
　　“”：告诉GDB上次请求命令不支持。
　　E：告诉GDB出错
　　OK：上次请求正确
　　W〈exit_status〉：系统在“exit_status”状态下退出。
　　X〈signal〉：系统在signal信号下终止。
　　S〈signal〉：系统在signal信号下停止。
　　O：告诉GDB控制台输出，这也是惟一向GDB发出的命令。
2 GDB远程调试功能
　　调试内核时通常还没有文件系统，而且多数嵌入式系统由于自身资源的限制不具备文件系统，因此将与文件系统有关的源文件、目标文件及符号表都存放在主机上，由主机上的调试器处理。同样，调试用的输入输出设备也是由主机提供。主机上的调试器接收用户输入的调试命令并进行预处理，对于某些命令(如breakpoint)的处理在主机GDB上实现，不需要与目标机通信。当然，更多的指令需要在目标机调试代理上实现。主机根据RSP对预处理之后的命令进行封装，发送给目标机上的调试代理，调试代理接收命令后作相应的处理，并返回信息给主机上的调试器。
3 目标机上stub的实现
　　目标机上stub的基本功能是与主机GDB通信，实现读写内存、寄存器，stop、continue指令。主机GDB与目标机上stub通信的通用模型如图2。

　　目标机与主机通过硬件连接，被调试部分插入stub，GDB与被调试部分通过RSP通信。根据stub所处层的不同实现不同层的调试，包括内核层、应用层的调试。
3.1 内核层调试模型
　　内核层调试模型如图3，将stub插入到内核可以实现内核的调试。Linux内核调试机制KGDB就是使用这种模式。KGDB可以分为初始化模块和控制模块。

3.1.1 初始化模块
　　修改异常处理" title="异常处理">异常处理函数，使得异常发生时进入函数handle_exception( )，GDB就能够捕获这些异常。初始化后使用breakpoint( )函数将系统控制权直接交给GDB。KGDB对异常处理函数的修改基本上可以分为二种，这两种方式均需先定义宏CHK_REMOTE_DEBUG：
　　#define CHK_REMOTE_DEBUG(trapnr，signr，error_code，regs，after) \
　　{ if(linux_debug_hook!=(gdb_debug_hook*) NULL && \
　　　　!user_mode(regs)) \
　　　　{ (*linux_debug_hook)(trapnr，signr，error_code，regs)；\
　　　　　　after；\
　　　　}\
　　}
　　(1)改变程序的流程，以int3的处理函数为例。
　　#define DO_VM86_ERROR(trapnr，signr，str，name) \
　　asmlinkage void do_##name(struct pt_regs*regs，long \
　　error_code) \
　　{ \
　　CHK_REMOTE_DEBUG(trapnr，signr，error_code，regs，goto skip_trap)\
　　do_trap(trapnr，signr，str，1，regs，error_code，NULL)；\
　　skip_trap：\
　　return；\
　　}
　　展开DO_VM86_ERROR(3，SIGTRAP，″int3″，int3)
　　asmlinkage void do_int3(struct pt_regs*regs，long
　　error_code)
　　{ if(linux_debug_hook！=(gdb_debug_hook*)NULL&&!
　　user_mode(regs))
　　{ (*linux_debug_hook)(3，SIGTRAP，errorcode，regs)；
　　　　goto skip_trap；
　　}
　　do_trap(3，SIGTRAP，″int3″，1，regs，error_code，NULL)；
　　skip_trap：
　　return；
　　}
　　由以上代码可见，进入内核调试状态后，异常处理函数就是handle_exception( )，程序流程跳过了非调试状态时的处理函数do_trap( )。
　　(2)不改变程序的流程，以异常divide_error 的处理函数为例。
　　#define DO_VM86_ERROR_INFO(trapnr，signr，str，name，sicode，siaddr) \
　　asmlinkage void do_##name(struct pt_regs*regs，long error_code) \
　　{ ……\
　　do_trap(trapnr，signr，str，1，regs，error_code，&info)； \
　　}
　　展开DO_VM86_ERROR_INFO( 0，SIGFPE，″divide error″，
　　divide_error，FPE_INTDIV，regs-〉eip)
　　asmlinkage void do_divide_error(struct pt_regs*regs，long
　　error_code)
　　{ if(linux_debug_hook！=(gdb_debug_hook*)NULL&&! user_mode(regs))
　　{ (*linux_debug_hook)(3，SIGTRAP，errorcode，regs)；
　　}
　　do_trap(0，SIGTRAP，″divide erro″，1，regs，error_code，&info)；
　　}
　　从以上代码看不出调试状态与非调试状态的区别，可以看一下do_trap函数可能会调用的函数die( )。
　　void die(const char*str，struct pt_regs*regs，long err)
　　{ ……
　　CHK_REMOTE_DEBUG(1，SIGTRAP，err，regs，)
　　……
　　do_exit(SIGSEGV)；
　　}
　　由此可见，调试状态下的异常处理函数还是进入了handle_exception函数。不过与上面一种异常不同之处在于：异常处理函数在调试与非调试状态下的程序流程是相同的，handle_exception只获取系统当时的状态，继续运行的结果还是do_exit。
　　虽然不是所有异常函数都是按上述两种方法定义，但本质上都一样。绝大多数处理函数的修改属于第二种，因为第一种异常是为调试准备的。因此在目标机具有调试输出设备的情况下，完全可以不修改第二种异常处理函数。因为Linux内核在非调试状态下的异常处理函数已经输出必要的状态信息、出错信息。
3.1.2 控制模块
　　控制模块与主机GDB通信的具体流程如图4。KGDB只调试内核态程序。handle_exception函数首先判断CPU是否处于VM86模式或用户态，若是则返回；然后接收GDB发来的信息，根据接收的信息作出相应的操作和回复。流程图内的虚线框是所有GDBstub中handle_exception函数的通用流程。

3.2 应用程序调试模型
　　在嵌入式Linux开发领域中调试应用程序常用调试代理工具GDBserver。其工作原理不是在被调试应用程序内编译stub，而是把被调试程序作为GDBserver的子进程，这样GDBserver可以利用内核提供的代码跟踪机制(ptrace)监控被调试进程的运行，从而完成调试任务。此工作原理与GDB本地调试相似。其调试模型如图5。GDBserver的工作流程是：GDBserver创建子进程－〉绑定跟踪ptrace(ptrace_traceme，，)－〉从主机传来的各种调试命令通过GDBserver转化为各种操作需求的ptrace。如果用GDBserver进行远程调试，需要内核操作系统的支持，包括子进程、代码跟踪机制，这样其他嵌入式系统内核工作量会较大。而且ptrace也有其局限性，例如只能跟踪子进程，在调试进程与被调试进程之间传送一个长字的数据。使用通用的调试模式工作量会更小。如图6，在应用程序中编译stub，并在应用程序入口处插入断点，程序开始将控制权交给GDB，之后的流程与内核层调试类似。