新闻中心

EEPW首页 > 嵌入式系统 > 嵌入式操作系统的调试

嵌入式操作系统的调试

——
作者:熊竞时间:2007-02-28来源:http://www.ibm.com/收藏

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

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

调试方案

一 插桩(stub)

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

  1. 调试器与被调试程序的通信
    调试器与目标操作系统通过指定通信端口(串口、网卡、并口)遵循远程调试协议进行通信。
  2. 被调试程序产生异常及时通知调试器
    目标操作系统的所有异常处理最终都要转向通信模块,告知调试器当前的异常号;调试器据此向用户显示被调试程序产生了哪一类异常。
  3. 调试器控制、访问被调试程序
    调试器的这类请求实际上都将转换成对被调试程序的地址空间或目标平台的某些寄存器的访问,目标操作系统接收到这样的请求可以直接处理。对于没有虚拟存储概念的简单的而言,完成这些任务十分容易。
  4. 调试器识别有关被调试程序的多任务信息并控制某一特定任务
    由目标操作系统提供相关接口。目标系统根据调试器发送的关于多任务的请求,调用该接口提供相应信息或针对某一特定任务进行控制,并返回信息给调试器。
  5. 调试器处理与目标硬件平台相关的信息
    第2条所述调试器应能根据异常号识别目标平台产生异常的类型也属于这一范畴,这类工作完全可以由调试器独立完成。支持多种目标平台正是GNU GDB的一大特色。

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



图1
图1

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



图2
图2

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

二 片上调试(On Chip Debugging)及Embedded PowerPC Background Debug Mode

片上调试是在处理器内部嵌入额外的控制模块,当满足了一定的触发条件时进入某种特殊状态。在该状态下,被调试程序停止运行,主机的调试器可以通过处理器外部特设的通信接口访问各种资源(寄存器、存储器等)并执行指令。为了实现主机通信端口与目标板调试通信接口各引脚信号的匹配,二者往往通过一块简单的信号转换电路板连接(如下图所示)。内嵌的控制模块以基于微码的监控器(microcode monitor)或纯硬件资源的形式存在,包括一些提供给用户的接口(如断点寄存器等)。具体产品有Motorola CPU16、CPU32、Coldfire系列的BDM(Background Debug Mode),Motorola PowerPC 5xx、8xx系列的EPBDM(Embedded PowerPC Background Debug Mode),IBM、TI的JTAG(Joint Test Action Debug,IEEE标准),还有OnCE、MPSD等等。下面以MPC860的EPBDM为例介绍片上调试方式。



图3
图3

EPBDM的运作相当于用处理器内嵌的调试模块接管中断及异常处理。用户通过设置调试许可寄存器(debug enable register)来指定哪些中断或异常发生后处理器直接进入调试状态,而不是操作系统的处理程序。进入调试状态后,内嵌调试模块向外部调试通信接口发出信号,通知一直在通信接口监听的主机调试器,然后调试器便可通过调试模块使处理器执行任意系统指令(相当于特权态)。所有指令均通过调试模块获取,所有load/store 均直接访问内存,缓存(cache)及存储管理单元(MMU)均不可用;数据寄存器被映射为一个特殊寄存器DPDR,通过mtspr和mfspr指令访问。调试器向处理器送rfi(return from interrupt)指令便结束调试状态,被调试程序继续运行。

与插桩方式的缺点相对应,OCD不占用目标平台的通信端口,无需修改目标操作系统,能调试目标操作系统的启动过程,大大方便了系统开发人员。随之而来的缺点是软件工作量的增加:调试器端除了需补充对目标操作系统多任务的识别、控制等模块,还要针对使用同一芯片的不同开发板编写各类ROM、RAM的初始化程序。

下面就以调试运行于MPC860的LINUX为例,说明用OCD方式调试OS 启动的某些关键细节。

首先,LINUX内核模块以压缩后的zImage形式驻留于目标板的ROM,目标板上电后先运行ROM中指定位置的程序将内核移至RAM并解压缩,然后再跳转至内核入口处运行。要调试内核,必须在上电后ROM中的指令执行之前获得系统的控制权,即进入调试状态、设断点,这样才能开展调试过程。MPC860的EPBDM提供了这一手段。

MPC860没有类似X86的INT 3那样能产生特定调试陷阱异常的指令,而操作系统内核往往具有针对非法指令的异常处理;为了使对内核正常运行的干扰降至最小,调试时应尽量设置硬件断点,而不是利用非法指令产生异常的"软"断点。

LINUX实现了虚存管理,嵌入式LINUX往往也有这一功能。地址空间从实到虚的转换在内核启动过程中便完成了,不论调试内核还是应用程序,调试器都无法回避对目标系统虚地址空间的访问,否则断点命中时根本无法根据程序计数器的虚地址显示当前指令,更不用说访问变量了。由于调试状态下转换旁视缓冲器(Translation Lookaside Buffer)无法利用,只能仿照LINUX内核TLB失效时的异常处理程序,根据虚地址中的页表索引位访问特定寄存器查两级页表得出物理页面号,从而完成虚实地址的转换。MPC860采用哈佛结构(Harvard architecture),指令和数据缓存分离设置(因为程序的指令段和数据段是分离的,这种结构可以消除取指令和访问数据之间的冲突),二者的TLB也分离设置;然而TLB失效时查找页表计算物理地址的过程是相同的,因为页表只有一个,不存在指令、数据分离的问题。虚实地址转换这一任务虽然完全落在了调试器一方,由于上述原因,再加上调试对象是嵌入式系统,一般不会有外存设备,不必考虑内存访问缺页的情况,所以增加的工作量并不大。



评论


相关推荐

技术专区

关闭