新型Linux开发工具应对下一代嵌入式系统设计挑战

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开发环境，有助于缩短客户产品上市时间，同时使开发人员能够实现优秀的代码质量。