RTEMS任务级别调试技术研究

4 面向任务的RTEMS调试
为了实现面向RTEMS任务的调试手段，将调试相关服务抽象成RTEMS任务和RTEMS中断处理程序。这样调试服务也将作为任务被RTEMS系统调度，当没有调试需求的时候，这些任务处于不可调度状态，不影响整个系统的运行。调试服务由以下三部分组成：
初始化任务，负责整个RTEMS调试服务的启动。
命令处理任务，与GDB交互，执行命令，并回复执行结果。
事件处理程序，获取任务中断信号，通知GDB被调试任务的状态。
这三部分的逻辑关系如图4所示。

4．1 调试任务说明
(1)初始化任务
初始化任务负责整个RTEMS调试服务的启动。它首先对GDB和调试服务之间的通信路径(串口或者网络接口)进行初始化，然后建立命令处理任务，并将事件处理程序与对应的软中断挂接起来。在初始化一切正常的情况下，初始化任务的历史使命彻底完成，它将自己删除。
(2)命令处理任务
命令处理任务由初始化任务建立。当GDB有命令到来的时候它被唤醒，接受命令，执行命令，并将执行结果发送回GDB。
现在整个调试服务都建立在RTEMS任务机制之上，又由于RTEMS支持POSIX接口规范，在“执行命令”阶段使用ptrace之类的系统调用来控制被调试任务是更好的选择。它可以降低调试服务和硬件平台的关联性，易于调试服务的移植和扩展。
在GDB发送继续执行命令(c命令或者s命令)的时候，命令处理程序对全局信号量DebugEvent进行一次V操作，使被调试程序成为可调度任务。
(3)事件处理程序
事件处理程序不是一个任务，而是一个软中断处理程序。当被调试程序遇到断点(软中断命令)的时候，处理器会转到事件处理程序上来。在STUB调试模式中，基本所有调试功能都在这个程序中完成，这就阻碍了RTEMS系统以及系统中其他任务的运行。
现在，事件处理程序只是报告GDB被调试程序中断发生，然后将对全局信号量DebugEvent进行一次P操作，使被调试任务进入不可调度状态。
在此要注意软中断的性质，它不同于真正的外部中断。用操作系统接口的概念来类比将更容易理解：当遇到一个软中断的时候，RTEMS将堆栈转换成对应任务的系统堆栈，但是此时仍然处于任务上下文当中，那么当然也就可以在事件处理程序中睡眠。
4．2 调试任务同步关系
通过任务优先等级和信号量来维持调试系统任务之间的同步关系。
首先，初始化任务和命令处理任务拥有相同的优先级――RTEMS中最高的优先级，其他所有应用的优先级都要低于此优先级，不能等于。这样就保证了GDB送来调试命令的时候，命令处理任务能够及时反应。
其次，使用全局DebugEvent信号量来控制被调试任务的调度状态。每次遇到断点，被调试任务进入事件处理程序(可看作是一个系统调用陷入)中，阻塞在事件处理程序的P操作之上。当命令处理任务收到被调试任务继续执行的命令时，对DebtagEvent信号量进行V操作，使被调试任务重新可调度。
最终调试服务的运行状态是：初始化任务在系统运行之初就删除了自己；在GDB不发送命令的时候，命令处理任务处于阻塞态，此时，RTEMS系统正常运行。当被调试任务遇到断点的时候，被调试任务阻塞在对Debu―gEvent信号量的P操作上，GDB得到被调试任务状态变化的通知，用户开始下达调试命令。GDB通过RSP传送给被调试端的每一条命令，都会将命令处理任务唤醒。命令处理位务迅速执行命令，将执行结果回复，然后重新进入到阻塞状态，等待下一条命令的到来。如果收到被调试任务继续执行的命令，命令处理任务对DebugEvent信号量进行V操作，使被调试任务得以继续被调度。
4．3 其他相关问题
第一个断点：为了不让被调试任务一下子运行到结尾(不给调试服务任何的执行机会)，需要在被调试任务的开头以手工修改代码的方式加入第一个断点。断点往往就是一个指定的软中断汇编指令(以i386为例，软中断对应汇编指令“int 3”)。此时，用户可以通过GDB远程下达调试命令，对被调程序进行正常调试，并设置后继的断点。可调试代码范围：首先，调试服务中用到的代码都是不可以被设置断点的，这样会引起调试服务的递归调用，系统会直接崩溃。其次，要避免在多个任务重入的代码中设置断点，这样有可能多个任务向GDB汇报遇到了断点，产生混乱。

结 语
本文对RTEMS操作系统的调试手段进行了探讨。其中STUB调试方式比较成熟，可以参考GDB源码中的．／gdb／i386一stub．c来理解STUB的工作方式。在此基础上，本文提出了面向任务的调试方式，在思路上延续STUB的路线，将调试服务分散到RTEMS任务和RTEMS软中断服务中去，实现了简单实用的面向任务的RTEMS调试手段。