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不预先占用内核，这对于以多数据和媒体为中心的应用而言非常关键。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。