The Pulse

Meta sviluppa un framework LLDB per il debugging di CPU e GPU

Un framework di plugin indipendente dai fornitori per il debugging con LLDB di applicazioni che utilizzano CPU e GPU mantiene la CPU e l’acceleratore come target separati, consentendo di gestirli in un’unica sessione di debugging.

AI.info Team · Scritto con l’IA · verificato · 2026-11-09

Un livello di debugging condiviso

Meta ha sviluppato, nel componente server di LLDB, un framework di plugin indipendente dai fornitori per il debugging di applicazioni che utilizzano CPU e GPU. Il progetto mantiene la CPU e l’acceleratore come processi di debugging separati, presentandoli però in un’unica sessione di debugging.

In un post pubblicato il 9 novembre, Meta ha descritto il lavoro come un modo per separare l’infrastruttura di debugging condivisa dal controllo dei dispositivi specifico per ciascun hardware. Il framework fornisce un livello comune, mentre i fornitori implementano il supporto per i propri dispositivi.

Mantenere distinti gli stati di host e dispositivo

Meta descrive la sfida come quella di un carico di lavoro che passa dal codice nativo della CPU ai kernel della GPU e viceversa, dove un bug può attraversare il confine tra i due. Il post osserva che CPU e GPU possono usare set di istruzioni, registri, spazi di memoria e modelli di esecuzione diversi, mentre l’esecuzione su GPU potrebbe non adattarsi al modello di thread usato dai debugger convenzionali.

Secondo Meta, i fornitori di GPU hanno storicamente sviluppato i propri strumenti di debugging, tra cui ROCgdb di AMD e CUDA-GDB di NVIDIA. Questi strumenti supportano le rispettive piattaforme, ma le funzioni comuni dei debugger possono richiedere implementazione e manutenzione separate.

Nel nuovo assetto, un backend specifico per l’hardware opera insieme al normale debugger per CPU di LLDB. Il backend traduce l’API di debugging dei dispositivi di un fornitore in concetti già utilizzati da LLDB, tra cui processi, thread, registri, memoria, moduli e motivi di arresto. Secondo Meta, questa suddivisione mantiene il client LLDB indipendente dai fornitori.

Per le applicazioni che usano solo la CPU, LLDB e lldb-server continuano a usare il percorso di debugging nativo esistente, senza costi computazionali aggiuntivi durante l’esecuzione, si legge nel post. Il supporto per il debugging delle GPU si attiva solo quando un’applicazione usa un runtime GPU supportato.

Coordinare una sessione di debugging

Il modello a due target assegna alla CPU e all’acceleratore target LLDB separati, ciascuno con la propria architettura e il proprio processo di debugging. Ogni processo mantiene i propri thread, registri, spazio di indirizzamento e stato di esecuzione, mentre entrambi i target possono comparire in un’unica sessione LLDB o IDE.

In una sessione tipica, LLDB si connette a lldb-server e rileva i plugin disponibili per gli acceleratori. Un plugin può chiedere a LLDB di impostare breakpoint interni nel processo host; quando l’host raggiunge un evento di runtime rilevante, lldb-server notifica il plugin, che inizializza l’API di debugging del fornitore e prepara una connessione al dispositivo.

Una volta connesso, il target dell’acceleratore può utilizzare le astrazioni già presenti in LLDB per thread, registri, memoria, moduli e breakpoint del dispositivo. Meta ha anche sviluppato un plugin che simula un acceleratore, per provare il processo senza hardware specializzato. La suite di test di LLVM può utilizzarlo per verificare il rilevamento dei plugin, il coordinamento dei breakpoint, la creazione della connessione e lo stato di base del dispositivo.

Lavoro nel progetto principale e prossimi passi

Meta ha integrato la maggior parte del framework comune nel progetto principale di LLVM. Il lavoro comprende l’interfaccia dei plugin di lldb-server, i pacchetti GDB-remote per il rilevamento e l’inizializzazione dei plugin, il coordinamento degli eventi di runtime e la creazione delle connessioni alle GPU, oltre al supporto per associare i processi di debugging di CPU e GPU mantenendo indipendenti le rispettive architetture.

Il lavoro integrato nel progetto principale comprende anche il supporto per più spazi di indirizzamento e test simulati indipendenti dall’hardware; Meta prevede di integrarvi presto le parti rimanenti. Meta intende completare il lavoro e ampliare le integrazioni con i fornitori; il suo obiettivo dichiarato è che il supporto per nuovo hardware richieda un plugin specifico del fornitore anziché un debugger separato.