Meta estende o LLDB com plugins para depurar aplicações que combinam CPUs e GPUs

A Meta construiu, dentro do lldb-server, uma interface de plugins para aceleradores que não depende de fornecedor. A ideia é traduzir a API de depuração de cada fabricante para conceitos que o LLDB já conhece: processos, threads, registradores, memória, módulos e motivos de parada. O cliente LLDB continua neutro, e o fornecedor cuida só do que é específico do seu hardware e driver.

O desenho trata CPU e GPU como dois alvos (targets) separados, cada um com seu processo de debugger, sua arquitetura e seu espaço de endereços. O desenvolvedor vê tudo numa sessão só, no LLDB ou na IDE. Isso evita forçar um mapa de memória único, em que o mesmo endereço 0x1000 pode apontar para lugares diferentes na CPU e na GPU. O fluxo usa breakpoints internos no processo do host: quando o runtime chega a um ponto-chave, o lldb-server avisa o plugin, que inicializa a API do fornecedor e abre um endpoint para o LLDB criar o segundo alvo.

Para aplicações só de CPU, o suporte a GPU não é ativado e não há custo computacional extra. A Meta também criou um plugin de acelerador simulado (mock), que permite testar descoberta, coordenação de breakpoints e criação de conexão na suíte de testes do LLVM sem hardware especializado. O framework cobre ainda depuração post-mortem, com plugins de core dump numa classe base comum. Segundo a empresa, a maior parte da base comum já foi enviada ao LLVM, e o restante deve vir em breve.

Para quem opera frotas heterogêneas de GPUs, a leitura é que ferramentas de depuração tendem a deixar de ser uma ilha por fornecedor. Se o modelo de plugin pegar, um mesmo fluxo de LLDB, protocolo remoto e IDE serviria a hardwares diferentes, o que facilita padronizar diagnóstico de falhas em cargas de IA. Ainda é uma direção anunciada, com parte do código por entrar no LLVM, então vale acompanhar antes de planejar em cima disso.