Linux 如今已在嵌入式实时操作系统(RTOS)领域占有一席之地。那些过去需要商用或自创及维护的 RTOS 应用正越来越多被 Linux 平台所取代。每家公司这样做的理由可能不尽相同，但共同的因素是：1)得到操作系统源代码的可能性；2)大量的设备驱动程序以及通信栈；3)精通 Linux 的软件工程师团队正日益壮大；4)从产品材料成本中减去操作系统版税部分能带来显而易见的成本优势；5)现在半导体供应商们为基于其硬件参考平台的系统级芯片(SoC)、工具链和参考发布提供了一个 Linux 端口。

为了充分利用 Linux 操作系统，原始设备制造商(OEM)可选择与商用 Linux 供应商合作，或在内部增添工程能力。这两种模式都已被证明是成功的，但是每种做法都需各自的成本。

不管 OEM 如何选择，他们的工程师所使用的典型调试模型都是相同的：基于 GDB(GNU Debugger)的客户服务器环境。如图1所示，它描述了在调试目标时，附加并运行在每个 Linux 进程中的 GDBSERVER 例示。每个 GDBSERVER 都通过一个以太网端口与主机通信。

另外，需要特别注意的是，采用这种调试方法，标准 Linux内核被替换成一种“静态”版本。仅有少数例外，所有通过 KGDB的目标调试通信都被限制在 RS232 串行链路。

图1: 标准 Linux 调试模型。

这种方法给开发人员带来了另一个挑战，即要使用 Linux内核的测试版(instrumented version)。虽然这是可接受的默认Linux调试环境，但这种方法有一些很明确的局限性。例如，采用多进程组成的应用，需要多个 GDBSERVER 运行于有限的目标存储器上。这可能影响被调试目标的性能，在一些情况下目标性能可降低50%以上。

即使在所有的内核工具和通信通道均可用的最佳情形下，仍有一些区域的代码在这个调试范例下难以到达。图2中说明的“问题”区域给内核和应用程序开发人员提出了更多挑战。这些区域包括每个进程下大量的线程，以及代码独立和数据位置独立的内核可加载模块。尽管对于熟练的开发人员来说，有可能利用现有技术合成一个环境，来满足这些区域的调试需要，但是这种环境对用户非常不友好，且在负载下无法扩展。

图 2: “问题”区域。

接下来我们看看在Linux 内核可加载模块的例子中，模块加载时间调用的初始化程序由哪些部分组成。目前的调试范例表明加载了这些模块，然后利用调试器对其代码和数据偏移进行调整(手动和自动)。但是，这时模块的初始化代码已经执行了，无法在代码所在区域对问题进行调试。另一个使用情形涉及共享库，这经常无法由 GDBSERVER 或其他类似程序很好地处理。即使存在这些问题，许多工程师仍在采用 printf(用户空间)和 printk(内核空间)作为主要调试帮助。一些调试“工具”带来新的软件问题或可能掩盖现有的问题。

Arriba Debugger全面解决嵌入式Linux调试问题

Arriba Debugger从一开始就计划为调试嵌入式 Linux 提供全面方案。VMON2取代了GDBSERVER 和 KGDB，是一种运行于嵌入式 Linux 目标的、动态可加载、基于需求的调试代理。通过与主机上的 Arriba Debugger 通信，从用户级线程到静态内核，VMON2 可实现 Linux 目标完全可视性。VMON2的存储器占位面积很小，即使在加载时，它对运行系统的性能影响也几乎无法觉察。VMON2 在目标上的空间小于 250KB，能通过单以太网连接到目标平台进行端到端的调试。

图3: Arriba 解决方案。

问题 1 – 可加载模块

通过 Arriba Debugger，当某一特性的内核模块加载到目标时，VMON2 可进行配置，并向主机发送信号。接到这个信号后，Arriba Debugger 会自动且正确地加载各自模块的符号信息，并对模块初始化功能的入口点进行位置控制。现在，用户可以通过高速以太网连接对有问题的模块进行充分调试控制。与传统Linux内核和模块的调试不同，VMON2不预先占用内核，这对于以多数据和媒体为中心的应用而言非常关键。

问题 2 – 多进程调试；父/子进程

在许多情况下，Linux 应用程序开发人员需要创建包括多进程的应用。这样的进程最初始于应用初始化程序中的一个父进程。一个常见的挑战是考虑设置子进程断点、并最终在子进程创建并运行时，满足这些断点的需求。这听起来也许很简单，但对现有的嵌入式或非嵌入式 Linux 调试来说尚未获得支持。作为一个变通办法，开发人员经常在由一个最初设为“真”变量选通的无限循环子进程中，人工插入用于测试的代码。这有助于将 GDBSERVER 这样的调试工具连接到有问题的子进程，将选通变量值变为“假”来解除循环并恢复调试。

问题 3 – 调试内核驱动程序、共享库…甚至已发布的产品内核

根据应用的范围和宽度，Linux 调试的“问题区域”范围可能涉及很广。Arriba Debugger 为将来可能发生的问题提供了一个彻底的解决方案。编程人员和现场应用工程师需要能诊断和修复那些出现在产品中，并已被部署到现场的缺陷。在这种情况下，目标平台取决于严格限制的调试和通信接入。作为可加载模块，VMON2 可进行配置来启动已经部署的系统，因此，它能够以极少的入侵有效调试并诊断系统。

Navigator集成元件套件(ICS)

MIPS 科技新发布了 MIPS Navigator集成元件套件(ICS)。Arriba Linux Debugger作为 MIPS Navigator ICS 的一个插件程序现可直接从 MIPS 科技获得。这种无缝集成是 MIPS 科技和 Viosoft 公司之间合作的结果。

MIPS Navigator ICS中是一个功能丰富的Eclipse CDT环境，是专为MIPS架构定制的。另外，MIPS Navigator ICS 还包含最新的基于GNU的MIPS工具链CodeSourcery SG++，以及全部开发代码必需的预期功能。MIPS Navigator ICS还集成了对所有MIPS科技的处理器IP的支持，包括PDTrace和EJTAG探针技术。

此外，开发人员还可利用另一款新的分析工具Arriba Linux Event Analyzer(LEA)，它也是MIPS Navigator ICS的一个插件程序。这款工具可捕捉发生在目标中的所有Linux事件，根据时间顺序用图表显示事件。Arriba LEA收集并提供大量关于Linux系统的信息，包括进程和线程间的上下文切换、信号和共用运行时间。LEA的存储器占位面积小，几乎不影响CPU周期，因此对于自主开发和现场服务而言都是理想的性能分析和调试工具。

图4: Linux Event Analyzer (LEA) ICS视图。

图4显示了一个LEA屏幕显示的例子。LEA可以检测外部事件延迟、响应时间，甚至是运行中的系统所出现的每个事件负载。该信息也可通过“原始”格式显示，易于导入Microsoft Excel进行其他后处理和分析。

终端用户的应用各不相同，同一组织内的每个开发人员或团队可能采用LEA系统的不同方面。这就需要开放端分析工具具有高度可定制的设计能力。通过创建和配置各自插入LEA的内核模块，开发人员可轻易且迅速地对其应用和系统进行观察。LEA采用与VMON2相同的测试技术(instrumentation technology)，这意味着不需要调试补丁或对Linux内核进行专门编译。

Arriba Linux Debugger、Arriba LEA 和 MIPS Navigator ICS 的组合为MIPS开发人员提供了一个全面而强大的Linux开发环境，有助于缩短客户产品上市时间，同时使开发人员能够实现优秀的代码质量。