扩展 LLDB 以调试跨 CPU 和 GPU 的应用

• 我们在 lldb-server 中构建了一个厂商中立的加速器插件架构，用于调试跨 CPU 和 GPU 的应用。它将共享调试器基础设施与硬件特定的设备控制分离。

• 该设计将 CPU 和 GPU 表示为独立的调试器进程，同时在同一个调试会话中呈现它们。

现代 AI 应用很少只在一个地方执行。一个工作负载可能从高层框架开始，并在原生 CPU 代码和 GPU 上运行的内核之间来回切换。当 bug 跨越这些边界时，开发者需要同时理解主机应用和设备。

这比将传统调试器附加到另一个进程更难。CPU 和 GPU 可能使用不同的指令集、寄存器、内存空间和执行模型。GPU 还通过主机进程内的运行时和驱动程序进行控制，因此调试设备通常需要与 CPU 仔细协调。

历史上，GPU 厂商构建了设备专用调试器，包括 AMD 的 ROCgdb 和 NVIDIA 的 CUDA-GDB。这些工具为各自平台提供深度支持，但通用调试器能力通常必须单独实现和维护。

在 Meta，我们一直在为 LLDB 开发一种不同的方法：lldb-server 中的通用加速器插件架构。在本文中，“GPU”指具体设备和示例，而“accelerator”指 LLDB 更广泛、厂商中立的插件抽象。该架构通过来自 Meta 工程师以及整个加速器生态的贡献而演进。它使共享调试器独立于任何单一 GPU，同时为硬件厂商提供一个专注实现设备特定行为的位置。

为什么 GPU 调试会挑战传统调试器模型

传统调试器通常假设一个进程有一种架构，并且对线程、寄存器和内存有一致视图。GPU 程序挑战了上述每一个假设。

主机进程可能运行在 x86-64 上，而其内核使用完全不同的指令集。CPU 线程具有熟悉的寄存器上下文，而 GPU 可能以锁步方式执行 lane 组。主机指针和设备指针可能指向不同的地址空间。GPU 可能暴露数千个执行 lane，这些 lane 无法清晰映射到大多数命令行和图形调试器所呈现的线程模型。

将所有这些状态组合到一个人为的进程模型中会使调试器更加复杂。每个操作都必须先确定它适用于 CPU 还是 GPU。寄存器处理、内存读取、断点、单步执行和停止事件都变得以所选硬件为条件。

这种分离使 LLDB 客户端保持厂商中立。对命令行、远程协议、符号处理和 IDE 集成的通用改进可以让每个加速器受益。同时，各厂商仍负责其硬件和驱动栈特有的细节。

仅当被调试应用程序使用受支持的 GPU 运行时，GPU 调试支持才会启用。对于仅 CPU 的应用程序，LLDB 和 lldb-server 继续走现有的原生调试路径，不会带来运行时计算开销。

两个目标，一种调试体验

该架构将 CPU 和加速器表示为独立的 LLDB 目标。每个目标都有自己的架构，并与一个调试器进程关联，该进程维护其线程、寄存器、地址空间和执行状态。CPU 继续使用 LLDB 既有的原生调试路径。当加速器可用时，插件会提供第二个连接，LLDB 使用该连接创建设备目标。

对调试器而言，这两个目标在技术上保持独立。对开发者而言，它们可以出现在同一个 LLDB 或 IDE 会话中。这避免了将不兼容的 CPU 和 GPU 概念强行塞进单个进程，同时仍支持统一的工作流。

协调主机与设备

典型的调试会话遵循一小组步骤：

• LLDB 连接到 lldb-server，并发现有哪些可用的加速器插件。

• 插件可以请求 LLDB 在主机进程中设置内部断点。这些断点用于标识重要的运行时事件，例如可以开始 GPU 调试会话的时刻。

• 当主机到达其中一个点时，lldb-server 会通知插件。插件初始化厂商调试 API，并准备加速器调试端点。

• LLDB 为加速器创建第二个目标并连接到它。随后，设备线程、寄存器、内存、模块和断点可以使用 LLDB 现有的抽象。

结构化操作协调双方。插件可以请求 CPU 断点、提供连接信息、报告设备模块，并同步主机与设备的执行。通用协议描述调试器需要做什么，而不会向 LLDB 客户端暴露厂商特定的 API 细节。

我们还构建了一个模拟加速器插件，它无需专用硬件即可演练此流程。它让 LLVM 测试套件能够验证发现、断点协调、连接创建和基本设备状态。这对于开发可独立于任何特定 GPU 进行审查和测试的共享基础设施非常重要。

典型的 GPU 工作流

以下为向量点积 HIP 示例产生的节选会话：

        (lldb) target list
Current targets:
  target #0: gpu_demo (x86_64, stopped)
* target #1: amd_memory_kernel[...] (amdgcn, stopped)

(lldb) b compute_element
Breakpoint 1: no locations (pending).
(lldb) c
(lldb) target select 0
(lldb) c
Launching kernel: 2 blocks x 32 threads
1 location added to breakpoint 1
Target 1 stopped.

(lldb) target select 1
(lldb) bt
* frame #0: compute_element(..., idx=32) at gpu_demo.hip:26
  frame #1: vector_dot_kernel(..., n=64) at gpu_demo.hip:35
      

跨硬件厂商的通用插件框架

插件边界有意基于调试器操作，而不是特定 GPU 平台的概念。这使其适用于指令集、运行时 API 和执行模型差异很大的各种设备。

该框架既支持实时会话，也支持 GPU 事后调试。GPU 核心转储插件为其 LLDB 集成使用一个通用基类，而厂商实现则提供设备特定的线程、寄存器、内存和模块状态。

扩展 LLDB 以调试跨 CPU 和 GPU 的应用程序

Meta 的 GPU 调试工作已经在利用这一架构。由于我们运营着异构的 GPU 集群，拥有不同的硬件和软件栈，这些工作使用同一模型这一事实是对该设计的重要验证：公共 LLDB 层可以保持稳定，而每个后端都能准确表示自己的设备。

在撰写本文时，我们已将大部分公共框架上游到 LLVM。这包括 lldb-server 插件接口；用于插件发现、初始化、运行时事件协调和 GPU 连接创建的 GDB-remote 数据包；支持在保留独立架构的同时关联 CPU 和 GPU 调试器进程；支持多个地址空间，以及硬件无关的模拟测试。我们预计很快会将剩余部分上游。

展望未来

接下来，我们计划完成剩余公共基础设施的上游，并扩展建立在其上的厂商集成。我们的目标是，将新硬件与 LLDB 集成应该只需要一个厂商特定插件，而不是需要构建和维护一个单独的调试器。

致谢