Meta 扩展 LLDB，用厂商中立加速器插件同时调试 CPU 与 GPU

.entry-header

作者： Greg Clayton, Satyanarayana Janga, Jeffrey Tan, Janet Yang, Bar Soloveychik, Chen Li, Vipul Bansal

我们在 lldb-server 中构建了一套厂商中立的加速器插件架构，用于调试横跨 CPU 和 GPU 的应用程序。它将共享的调试器基础设施与硬件专属的设备控制分离。
该设计将 CPU 和 GPU 表示为两个独立的调试器进程，同时在同一个调试会话中呈现它们。

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

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

历史上，GPU 厂商构建了设备专属的调试器，包括 AMD 的 ROCgdb 和 NVIDIA 的 CUDA-GDB。这些工具为其各自的平台提供了深度支持，但常见的调试器能力往往需要分别实现和维护。

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

为什么 GPU 调试对传统调试器模型构成挑战

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

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

将所有这些状态合并到一个人为的进程模型中，会让调试器变得更加复杂。每个操作都必须首先判断它适用于 CPU 还是 GPU。寄存器处理、内存读取、断点、单步执行和停止事件都变得取决于所选硬件。单一进程模型还会迫使 CPU 和 GPU 进入同一个统一的内存映射，尽管它们的地址空间可能相互独立：同一个地址（例如 0x1000）在 CPU 进程和 GPU 进程中可能指向不同的位置。

LLDB 加速器架构没有隐藏这些差异，而是为它们划定了清晰的边界。

lldb-server 中对 GPU 调试的插件支持

LLDB 使用一个名为 lldb-server 的伴随进程来启动或附加到程序，并执行底层调试操作。LLDB 客户端通过 GDB 远程协议与服务器通信，该协议是一种命令协议，用于读取内存、检查寄存器、控制执行和设置断点等操作。

由于 lldb-server 已经控制着原生进程，它也是与加速器运行时协调的合适位置。新的插件接口让硬件专属后端能够与常规 CPU 调试器协同工作。该后端将厂商的设备调试 API 转换为 LLDB 已经理解的概念，例如进程、线程、寄存器、内存、模块和停止原因。

这种分离使 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 模块加载时解析，而回溯
来自 GPU 目标。

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

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

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

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

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

展望未来

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

致谢

我们感谢 Meta 开发者基础设施领导团队，特别是 Shane Nay、Todd Fiala 和 Ale Contenti，他们的直接支持使这项工作成为可能。

我们还要感谢调试与工具团队的同事 Jacob Lalonde、David Young、Alexandre Perez、Zhiyuan Li、Piyush Jaiswal 和 Philip DePetro 的协作与支持。

最后，我们感谢开源社区，特别是 Jonas Devlieghere、Jim Ingham、David Spickett 和 Jason Molenda，感谢他们审阅 RFC 和上游拉取请求。

分享此内容：

.entry-content