Meta's lldb-server GPU debugging plugin goes upstream to LLVM

Meta's post explains that modern AI workloads often move between native CPU code and GPU kernels, and a bug that crosses those boundaries requires understanding both sides together. Traditional debuggers assume one process has one architecture and a consistent view of threads, registers, and memory. GPU programs break each of those assumptions: a host process might run on x86-64 while its kernels use a completely different instruction set, and the same address such as 0x1000 can refer to different locations in the CPU and GPU processes. Rather than hiding those differences, the LLDB accelerator architecture gives them a clear boundary by representing the CPU and accelerator as separate LLDB targets, each with its own architecture and associated debugger process.

The plugin interface sits in lldb-server, which already controls the native process and communicates with the LLDB client through the GDB remote protocol. A hardware-specific backend translates a vendor's device debugging API into concepts LLDB already understands, such as processes, threads, registers, memory, modules, and stop reasons. This keeps the LLDB client vendor-neutral, so common improvements to the command line, remote protocol, symbol handling, and IDE integration can benefit every accelerator, while each vendor remains responsible for details unique to its hardware and driver stack. The post notes that GPU debugging efforts at Meta are already leveraging the architecture across a heterogeneous fleet of GPUs, which the company calls an important validation of the design.

Meta says it has upstreamed most of the common framework to LLVM, including the lldb-server plugin interface, GDB-remote packets for plugin discovery and coordination, support for associating CPU and GPU debugger processes while preserving their independent architecture, support for multiple address spaces, and hardware-independent mock tests. The stated goal is that integrating new hardware with LLDB should require only a vendor-specific plugin, not a separate debugger to build and maintain.