The Pulse
Meta builds LLDB framework for CPU-GPU debugging
A vendor-neutral plugin framework for debugging applications across CPUs and GPUs with LLDB keeps the CPU and accelerator as separate targets while allowing them to be handled in one debugging session.
AI.info Team · Written with AI · fact-checked ·
A shared debugger layer
Meta built a vendor-neutral plugin framework in LLDB’s server component for debugging applications that span CPUs and GPUs. The design keeps the CPU and accelerator as separate debugger processes while presenting them in a single debugging session.
In a post published Nov. 9, Meta described the work as a way to separate shared debugger infrastructure from hardware-specific device control. The framework provides a common layer while vendors implement support for their own devices.
Keeping host and device state distinct
Meta describes the challenge as a workload moving between native CPU code and GPU kernels, where a bug may cross the boundary. The post notes that CPUs and GPUs can use different instruction sets, registers, memory spaces and execution models, while GPU execution may not fit the thread model used by conventional debuggers.
GPU vendors have historically built their own debugging tools, including AMD’s ROCgdb and NVIDIA’s CUDA-GDB, Meta says. Those tools support their respective platforms, but common debugger functions can require separate implementation and maintenance.
Under the new arrangement, a hardware-specific backend works alongside LLDB’s normal CPU debugger. The backend translates a vendor’s device-debugging API into concepts LLDB already uses, including processes, threads, registers, memory, modules and stop reasons. That division leaves the LLDB client vendor-neutral, according to Meta.
For CPU-only applications, LLDB and lldb-server continue using the existing native debugging path, with no runtime computational overhead, the post says. GPU debugging support is activated only when an application uses a supported GPU runtime.
Coordinating a debugging session
The two-target model gives the CPU and accelerator separate LLDB targets, each with its own architecture and debugger process. Each process maintains its own threads, registers, address space and execution state, while both targets can appear in one LLDB or IDE session.
In a typical session, LLDB connects to lldb-server and discovers available accelerator plugins. A plugin can ask LLDB to set internal breakpoints in the host process; when the host reaches a relevant runtime event, lldb-server notifies the plugin, which initializes the vendor debugging API and prepares a device connection.
Once connected, the accelerator target can use LLDB’s existing abstractions for device threads, registers, memory, modules and breakpoints. Meta also built a mock accelerator plugin to exercise the process without specialized hardware. The LLVM test suite can use it to check plugin discovery, breakpoint coordination, connection creation and basic device state.
Upstream work and next steps
Meta has upstreamed most of the common framework to LLVM. The work includes the lldb-server plugin interface, GDB-remote packets for plugin discovery and initialization, runtime-event coordination and GPU connection creation, as well as support for associating CPU and GPU debugger processes while keeping their architectures independent.
The upstreamed work also covers multiple address spaces and hardware-independent mock tests, and Meta expects to upstream the remaining pieces soon. Meta plans to complete that work and expand vendor integrations; its stated goal is for new hardware support to need a vendor-specific plugin rather than a separate debugger.