---
type: "post"
id: "extending-lldb-to-debug-applications-that-span-cpus-b18d97"
slug: "extending-lldb-to-debug-applications-that-span-cpus-b18d97"
title: "Extending LLDB to Debug Applications That Span CPUs and GPUs"
description: "Meta has built a vendor-neutral accelerator plugin architecture for LLDB’s server, enabling a CPU application and its GPU kernels to be debugged as separate targets in one session."
retrieval_nugget: "Meta has built a vendor-neutral accelerator plugin architecture for LLDB’s server, enabling a CPU application and its GPU kernels to be debugged as separate targets in one session."
published_at: "2026-11-10"
updated_at: "2026-11-10"
record_date: "2026-11-10"
date_kind: "published_at"
topics: ["developer-tools","compute"]
entities: ["Meta","LLDB","LLVM","HIP","Greg Clayton","Satyanarayana Janga","Jeffrey Tan"]
related_patterns: []
novelty_label: "new_fact"
what_changed: "Meta describes a vendor-neutral LLDB accelerator plugin architecture for debugging CPU and GPU code together in one session."
prior_refs: []
source_url: "https://engineering.fb.com/2026/11/09/developer-tools/extending-lldb-to-debug-applications-that-span-cpus-and-gpus"
source_urls: ["https://engineering.fb.com/2026/11/09/developer-tools/extending-lldb-to-debug-applications-that-span-cpus-and-gpus"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:extending-lldb-to-debug-applications-that-span-cpus-b18d97"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/extending-lldb-to-debug-applications-that-span-cpus-b18d97/","markdown":"https://newruntime.com/posts/extending-lldb-to-debug-applications-that-span-cpus-b18d97.md","json":"https://newruntime.com/posts/extending-lldb-to-debug-applications-that-span-cpus-b18d97.json"}
markdown_url: "https://newruntime.com/posts/extending-lldb-to-debug-applications-that-span-cpus-b18d97.md"
---

# Extending LLDB to Debug Applications That Span CPUs and GPUs

## Retrieval answer

Meta has built a vendor-neutral accelerator plugin architecture for LLDB’s server, enabling a CPU application and its GPU kernels to be debugged as separate targets in one session.

## Summary
Meta has built a vendor-neutral accelerator plugin architecture for LLDB’s server, enabling a CPU application and its GPU kernels to be debugged as separate targets in one session. Most of the shared framework has been upstreamed to LLVM; Meta says it plans to upstream the remaining pieces and expand vendor integrations. For teams debugging heterogeneous workloads, the design could reduce duplicated debugger infrastructure without hiding device-specific behavior.

## What happened
Meta’s Engineering post, published November 9, 2026, describes an accelerator plugin architecture in `lldb-server`, LLDB’s companion process for launching or attaching to programs and performing low-level debugging operations. The system is meant for applications that move between native CPU code and GPU kernels. That debugging is difficult because CPU and GPU code can use different instruction sets, registers, memory spaces and execution models. A GPU is also controlled through a runtime and driver inside the host process, so debugging the device requires coordination with the CPU.

The design keeps the CPU and accelerator as separate LLDB targets, each with its own architecture and debugger process, including its own threads, registers, address space and execution state. The CPU continues to use LLDB’s existing native path. When a supported accelerator runtime is detected, a plugin can initialize the vendor debugging API and provide LLDB with a second connection. Developers can then work with both targets through one LLDB or IDE session, without forcing incompatible host and device concepts into one artificial process model.

The plugin runs alongside the normal CPU debugger in `lldb-server`. Hardware-specific backends translate a vendor’s device-debugging API into LLDB concepts such as processes, threads, registers, memory, modules and stop reasons. The LLDB client therefore remains vendor-neutral, while vendors retain responsibility for details specific to their hardware and driver stacks. Meta says common improvements to LLDB’s command line, remote protocol, symbol handling and IDE integration can benefit each accelerator. GPU support activates only when the application uses a supported GPU runtime; CPU-only applications continue on the existing path without runtime computational overhead.

A session starts with LLDB discovering 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. The plugin initializes the vendor API, prepares an accelerator endpoint, and LLDB creates and connects a second target. Structured actions coordinate CPU breakpoints, device modules and synchronized host/device execution. Meta also built a mock plugin so the LLVM test suite can exercise discovery, breakpoint coordination, connection creation and basic device state without specialized hardware.

Meta illustrates the workflow with a vector dot-product HIP sample. A breakpoint on `compute_element` is initially pending; after the GPU module loads, the breakpoint resolves and the device target stops. The developer can select that target and inspect a backtrace from the GPU kernel. The post says the framework supports live and postmortem GPU debugging, and that GPU core-dump plugins can share a common LLDB integration base while vendor implementations provide device-specific state. Meta says most common infrastructure has been upstreamed to LLVM, including the plugin interface, GDB-remote packets, target association, multiple-address-space support and mock tests. The remaining pieces are expected to follow. The post gives no price or separate access terms.

## What the archive adds
New Runtime’s earlier coverage described Epic Games’ RAD Debugger as a native, user-mode graphical debugger for multiple processes ([October 7, 2026 note](https://newruntime.com/posts/epicgames-raddebugger-analysis-e8416a/)). That is related in the broad area of debugger tooling, not the same implementation or event. Meta’s post is a new event and a more specific account of how a debugger can coordinate CPU and accelerator state while keeping their process models separate.

## Trend signal
This does not yet fit a pattern New Runtime tracks. The post describes debugger architecture and vendor integration, but does not establish a broader shift in agent design, interoperability protocols or AI operating models.

## Why now
Meta says its heterogeneous GPU fleet includes different hardware and software stacks, and that its GPU debugging efforts are already using the architecture. The company presents that use as validation of a common layer that can remain stable while individual backends represent device-specific behavior. It also reports that most of the shared infrastructure has reached LLVM, making upstream integration part of the current development story rather than a future aspiration alone.

## Why it matters
Teams debugging AI applications often have to cross boundaries between framework code, native host code and accelerator kernels. Separate vendor debuggers can provide deep hardware-specific support, but Meta says common capabilities may then need to be implemented and maintained independently. A shared LLDB integration offers a different trade-off: a familiar debugger interface and common handling for breakpoints, symbols and IDE integration, with vendor-specific code concentrated in plugins.

The architectural choice to represent CPU and GPU as separate targets is important. It preserves the real differences in instruction sets and address spaces instead of pretending they are one process, while still allowing one debugging session to coordinate them. That may make cross-boundary failures easier to inspect for developers whose supported runtimes and vendor backends work with the framework. It does not mean every GPU is automatically supported: the useful coverage depends on vendor integrations and their device-debugging APIs. Teams should treat this as an emerging shared foundation, not a turnkey universal GPU debugger.

## Limits and uncertainty
Meta describes the architecture and provides a HIP sample, but the post does not quantify debugging time saved, adoption beyond its own GPU efforts, or how many vendors have completed integrations. It says most shared infrastructure is upstreamed and the remaining pieces are expected soon; it does not specify a completion date. Device support still depends on vendor-specific backends, compatible runtimes and drivers. Meta’s account is not an independent evaluation, and the mock plugin tests coordination flows without specialized hardware rather than proving behavior across all real devices.

## Reader takeaway
Meta’s LLDB work is a shared debugging foundation, not a universal GPU debugger. Its central design move is to keep CPU and accelerator targets technically distinct while coordinating them in one session. For teams with heterogeneous workloads, the practical question is whether the vendor and runtime they use will implement the plugin side and upstream the required support.

## Open question
Which accelerator vendors will complete integrations against the upstream LLDB framework, and how broadly will those integrations support live and postmortem debugging?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Developer Tools](https://newruntime.com/topics/developer-tools.md): Explore the developer-tools topic hub.
- topic hub: [Compute](https://newruntime.com/topics/compute.md): Explore the compute topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)