# Extending LLDB to Debug Applications Spanning CPUs and GPUs Meta develops a vendor-neutral plugin architecture for unified cross-hardware debugging in LLDB. - **Source:** [Facebook Engineering](https://engineering.fb.com) - **Published:** 2026-11-09 - **Topic:** [technology](https://brifing.si/c/technology) - **Original article:** - **On Brifing:** https://brifing.si/s/098c207b-ccf3-4a65-8aa6-b836b431a9d1 ## Unified Debugging Architecture Meta has introduced a vendor-neutral accelerator plugin architecture within lldb-server to facilitate debugging for applications spanning both CPUs and GPUs. This design separates shared debugger infrastructure from hardware-specific device control. By representing CPUs and GPUs as distinct processes, it enables developers to manage complex, heterogeneous workloads within a single debugging session. ## Addressing Hardware Complexity Modern AI applications frequently transition between native CPU code and GPU kernels, creating significant debugging challenges. CPUs and GPUs utilize different instruction sets, registers, and memory spaces, making traditional single-process debugger models insufficient. This new architecture avoids forcing incompatible hardware concepts into a single process, instead maintaining clear boundaries between targets. ## Plugin Interface Functionality The new plugin interface allows hardware-specific backends to operate alongside the standard CPU debugger. It translates vendor-specific device APIs into LLDB-compatible concepts like threads, registers, and memory. This approach ensures that common improvements to command-line tools or IDE integrations benefit all accelerators while keeping the core LLDB client vendor-neutral. ## Coordinating Host and Device Debugging sessions are coordinated through lldb-server, which manages connections to both CPU and accelerator targets. Plugins set internal breakpoints in the host process to identify runtime events, such as when a GPU session should initialize. This structured coordination allows the debugger to synchronize execution states without exposing vendor-specific details to users. ## Independent Target Management The architecture treats the CPU and accelerator as separate LLDB targets, each maintaining its own execution state and address space. This independence prevents conflicts between different memory maps, such as when the same address refers to different locations on the CPU and GPU. Developers interact with these targets through a unified interface. ## Testing with Mock Plugins To ensure stability, the team developed a mock accelerator plugin that exercises the debugging flow without requiring specialized hardware. This tool allows the LLVM test suite to verify critical functions like discovery, breakpoint coordination, and connection creation. It has been essential for reviewing shared infrastructure independently of any specific GPU vendor. ## Upstreaming to LLVM Meta has already upstreamed the majority of this common framework to the LLVM project. This includes the lldb-server plugin interface, GDB-remote packets for discovery, and support for multiple address spaces. The team plans to upstream the remaining components soon, aiming to simplify the integration process for future hardware vendors and developers. ## Impact on Future Development By standardizing the plugin model, Meta aims to eliminate the need for maintaining separate, vendor-specific debuggers like ROCgdb or CUDA-GDB. This unified approach supports both live debugging and postmortem core-dump analysis. As heterogeneous computing becomes standard, this stable, common LLDB layer provides a scalable foundation for debugging across diverse hardware and software stacks. ## Sources covering this story - https://engineering.fb.com/2026/11/09/developer-tools/extending-lldb-to-debug-applications-that-span-cpus-and-gpus/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._