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(内核空间)作为主要调试帮助。一些调试“工具”带来新的软件问题或可能掩盖现有的问题。