嵌入式LINUX系统的静/动态集成调试模式

发布时间:2008/5/27 0:00:00 访问次数:406

现有的嵌入式linux系统开发过程中，所有的工程师都疲惫于使用两种不同的调试模式分别调试系统的内核和应用程序。首先通过一个jtag调试工具来配置和启动linux系统；嵌入式linux系统正常运行起来后，就要通过gdb来继续调试工作。

lauterbach公司综合了上述两种传统调试技术特长提供了一种新的linux调试技术。

本文以arm架构上的linux系统开发为例，详细介绍和对比这三种不同的调试模式的实现和应用。

静态调试模式

通过jtag调试接口进行软件调试的工具一般都只能工作在静态调试模式下，处理器和整个系统都必须被同时挂起。然后调试工具通过jtag接口把处理器和目标系统的当前状态获取并显示出来（如图1所示）。

静态调试模式具有如下的优点：

● 静态调试模式唯一的环境需求就是目标系统必须支持jtag调试标准，该调试模式最大的优点就是可以支持从复位向量表开始调试；
　
● 只要调试工具支持linux和mmu调试，就可以实现对linux内核及进程越界等问题的调试；

● 如果软件异常，随时可以挂起处理器，查看当前错

误代码及系统状态；
　　
● 因为处理器处于挂起状态，内核和其它进程都不会再对系统造成任何的干扰。

然而静态调试模式也有其不足之处，一旦处理器被挂起，所有的通信接口进程同时被终止。造成的结果就是所有通过ethernet、bluetooth或者 can等接口和处理器进行通信的外部设备，都会因为等待响应超时而中断连接。因此通过静态模式进行调试时，即使你只调试其中的一个进程或函数，也有可能改变整个系统的状态和配置；接下来再继续运行和调试程序，就无法保证系统的完整性和连续性，所以后续的调试可能就没有任何意义。

动态调试模式

gdb 调试模式是嵌入式linux系统的通用的动态调试模式。在该模式下，可以实现只对当前进程挂起，系统的内核和其它的所有进程都继续处于运行状态。

然而gdb是一个纯粹的软件调试工具，同时需要下面的软件环境才可以实现：

● 目标系统上要有活动的gdb server linux进程
　
● 主机端要有相应的调试软件，例如trace32（如图2所示）

trace32与gdb server通过rs232或者ethernet接口进行通信，收集当前被挂起的进程的状态信息。但是要实现动态调试模式，还必须建立在如下两个条件都成立的基础之上：

● 目标系统已经被完全正确的初始化并正确启动
　　
● gdb server 永远处于活动状态——即通信接口已经正确运行，处理器或gdb server不会被其它程序错误的挂起

综上所述，两种调试模式都有各自的优点和不足，静态调试模式比较容易实现，操作也比较简单，但是无法保证系统的连续和完整性；动态调试模式环境需求比较复杂。因此，lauterbach提供了可以实现上述两种调试模式的调试工具，在完全克服了各自的缺陷的同时充分发挥了各自的优势，实现了嵌入式 linux调试技术的飞跃。

　　集成的静态和动态调试模式

　　针对嵌入式linux系统，支持集成的静态和动态调试模式的trace32调试工具工作原理如下（如图3所示）：

1. trace32调试工具通过jtag接口进入静态调试模式。在静态模式下首先完成对目标系统的硬件和动态调试模式（gdb）的环境配置。
　
2. 如果目标系统初始化和启动程序是调试重点，就使用静态调试模式进行调试。
　　
3. 目标系统正确启动完成后，trace32可以切换为动态调试模式，从而实现对应用程序的动态调试。
　　
4. 如果在动态调试过程中，需要对系统重新做新的配置和初始化。trace32也支持随时再把系统切换到静态调试模式。

同时，由于集成的静态和动态调试模式的实现，下面的许多新属性也被添加到动态调试模式里。

● 对于基于arm架构的处理器，可以以调试通信通道（dcc）为动态调试模式的信息通信接口。这样只需要一个jtag接口就可以支持集成的静态和动态调试模式。
　
● 对两个或多个进程进行同时调试。

将dcc作为通信接口

在arm的架构下，jtag接口中已经包含dcc通信接口。当应用程序在目标处理器上运行时，从原理上讲通过dcc实现如下两个模块间信息通信是完全可行的。

● 主机端的调试软件

● 目标系统上的任何应用程序—通过gdb server

因此，如果trace32 采用dcc 作为和gdb server 通信的接口，就不再需要额外的通信接口来实现对动态调试模式的支持（如图4所示）。

多个进程同时调试

在实际的调试过程中，经常需要对多个进程进行同时的调试。为了实现该属性，la