谈谈嵌入式操作系统的调试问题

　　调试是开发过程中必不可少的环节，通用的桌面操作系统与嵌入式操作系统在调试环境上存在明显的差别。前者，调试器与被调试的程序往往是运行在同一台机器、 相同的操作系统上的两个进程，调试器进程通过操作系统专门提供的调用接口(早期UNIX系统的ptrace调用、如今的进程文件系统等)控制、访问被调试 进程。后者(又称为远程调试)，为了向系统开发人员提供灵活、方便的调试界面，调试器还是运行于通用桌面操作系统的应用程序，被调试的程序则运行于基于特定硬件平台的嵌入式操作系统(目标操作系统)。这就带来以下问题：调试器与被调试程序如何通信，被调试程序产生异常如何及时通知调试器，调试器如何控制、访问被调试程序，调试器如何识别有关被调试程序的多任务信息并控制某一特定任务，调试器如何处理某些与目标硬件平台相关的信息(如目标平台的寄存器信息、机器代码的反汇编等)。

　　我们介绍两种远程调试的方案，看它们怎样解决这些问题。

　　调试方案

　　一 插桩(stub)

　　第一种方案是在目标操作系统和调试器内分别加入某些功能模块，二者互通信息来进行调试。上述问题可通过以下途径解决：

　　调试器与被调试程序的通信

　　调试器与目标操作系统通过指定通信端口(串口、网卡、并口)遵循远程调试协议进行通信(远程调试协议详见http://rtos.ict.ac.cn/rtos/debugger/)。

　　被调试程序产生异常及时通知调试器

　　目标操作系统的所有异常处理最终都要转向通信模块，告知调试器当前的异常号;调试器据此向用户显示被调试程序产生了哪一类异常。

　　调试器控制、访问被调试程序

　　调试器的这类请求实际上都将转换成对被调试程序的地址空间或目标平台的某些寄存器的访问，目标操作系统接收到这样的请求可以直接处理。对于没有虚拟存储概念的简单的嵌入式操作系统而言，完成这些任务十分容易。

　　调试器识别有关被调试程序的多任务信息并控制某一特定任务

　　由目标操作系统提供相关接口。目标系统根据调试器发送的关于多任务的请求，调用该接口提供相应信息或针对某一特定任务进行控制，并返回信息给调试器。

　　调试器处理与目标硬件平台相关的信息

　　第2条所述调试器应能根据异常号识别目标平台产生异常的类型也属于这一范畴，这类工作完全可以由调试器独立完成。支持多种目标平台正是GNU GDB的一大特色。

　　综上所述，这一方案需要目标操作系统提供支持远程调试协议的通信模块(包括简单的设备驱动)和多任务调试接口，并改写异常处理的有关部分。另外目标操作系统还需要定义一个设置断点的函数;因为有的硬件平台提供能产生特定调试陷阱异常(debug trap)的断点指令以支持调试(如X86的INT 3)，而另一些机器没有类似的指令，就用任意一条不能被解释执行的非法(保留)指令代替。目标操作系统添加的这些模块统称为"插桩"(见下图)，驻留于 ROM中则称为ROM monitor。通用操作系统也有具备这类模块的：编译运行于Alpha、Sparc或PowerPC平台的LINUX内核时若将kgdb开关打开，就相当于加入了插桩。

　　图1

　　运行于目标操作系统的被调试的应用程序要在入口处调用这个设置断点的函数以产生异常，异常处理程序调用调试端口通信模块，等待主机(host)上的调试器发送信息。双方建立连接后调试器便等待用户发出调试命令，目标系统等待调试器根据用户命令生成的指令。这一过程如下图所示。

　　图2

　　这一方案的实质是用软件接管目标系统的全部异常处理(exception handler)及部分中断处理，在其中插入调试端口通信模块，与主机的调试器交互。它只能在目标操作系统初始化，特别是调试通信端口初始化完成后才起作用，所以一般只用于调试运行于目标操作系统之上的应用程序，而不宜用来调试目标操作系统，特别是无法调试目标操作系统的启动过程。而且由于它必然要占用目标平台的某个通信端口，该端口的通信程序就无法调试了。最关键的是它必须改动目标操作系统，这一改动即使没有对操作系统在调试过程中的表现造成不利影响，至少也会导致目标系统多了一个不用于正式发布的调试版。

原文转自：http://www.uml.org.cn/Test/2003123145.htm