💻 computer science

GapForge: Directed Compiler Fuzzing via Coverage-Gap Analysis

O GapForge é uma técnica de fuzzing de compiladores baseada em LLM direcionada que identifica e preenche sistematicamente lacunas de cobertura de cauda longa ao priorizar arquivos subcobertos, inferir requisitos de gatilho de granularidade fina através de análise de diferença de caminho e sintetizar prompts iterativamente para superar significativamente os métodos existentes em cobertura e descoberta de bugs no GCC e LLVM.

Autores originais: Mingxuan Zhu, Qingyuan Liang, Junjie Chen, Zhihong Xue, Dan Hao

Publicado 2026-07-20

📖 4 min de leitura☕ Leitura rápida

CC BY 4.0

Autores originais: Mingxuan Zhu, Qingyuan Liang, Junjie Chen, Zhihong Xue, Dan Hao

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine o software que roda o seu telefone, o seu carro ou a internet como uma gigantesca e invisível fábrica. Dentro desta fábrica, existem milhões de pequenos trabalhadores (linhas de código) que pegam as suas instruções de alto nível e as transformam na linguagem de máquina que o computador entende. Esta fábrica é chamada de compilador. Se apenas um trabalhador for preguiçoso, confuso ou quebrar uma regra, a fábrica inteira pode produzir produtos lixo — programas que travam, congelam ou secretamente fazem a coisa errada. Como essas fábricas são tão enormes e complexas, é incrivelmente difícil garantir que cada um dos trabalhadores esteja sendo vigiado e testado.

Entre no mundo do teste de software. Pense nisso como enviar uma equipe de inspetores para ver se a fábrica está funcionando corretamente. Durante anos, os inspetores usaram dois truques principais: ou eles jogam dardos aleatórios na fábrica (teste aleatório) ou tentam quebrar as coisas tentando distorcer instruções existentes (teste de mutação). Mas aqui está o problema: os inspetores continuam atingindo os mesmos cantos fáceis de alcançar da fábrica, deixando os fundos empoeirados, escuros e de difícil acesso completamente ignorados. Esses "pontos cegos" são onde os bugs mais perigosos se escondem, esperando para causar problemas. Recentemente, cientistas começaram a usar Modelos de Linguagem de Grande Escala (LLMs) — IAs superinteligentes que conseguem escrever código — para ajudar nas inspeções. Mas mesmo esses ajudantes de IA muitas vezes vagam sem rumo, sem saber exatamente quais cantos escuros precisam de mais luz.

É aqui que uma nova técnica chamada GapForge entra em cena, agindo como um detetive com um mapa mágico. Em vez de apenas jogar dardos ou adivinhar, o GapForge olha para um mapa da fábrica para ver exatamente quais salas nunca foram visitadas. Ele então usa seu cérebro de IA para descobrir o "aperto de mão secreto" específico (um tipo específico de código e uma configuração especial) necessário para abrir essas portas trancadas. Os pesquisadores testaram isso em duas das maiores fábricas de compiladores do mundo, GCC e LLVM. Eles descobriram que o GapForge é um mestre em encontrar essas salas escondidas. Em apenas 72 horas, ele cobriu 68,13% do código principal do GCC e 69,11% do código do LLVM. Isso pode não parecer 100%, mas lembre-se, o melhor método de IA anterior conseguiu gerenciar apenas cerca de 64,62% e 65,02%. O GapForge não apenas deu um empurrão nos números; ele encontrou 24.736 linhas de código a mais no GCC e 19.798 a mais no LLVM que os outros métodos perderam completamente.

Como ele faz isso? Pense no GapForge como um processo de três etapas. Primeiro, ele escaneia o mapa da fábrica e escolhe a sala "mais suja" — aquela com o código mais não testado. Segundo, em vez de apenas olhar para o quarto inteiro, ele dá um zoom no ponto empoeirado específico e pergunta à IA: "Que tipo de chave precisamos para abrir este lugar?". A IA analisa as áreas limpas ao redor para adivinhar a combinação exata de estruturas de código e configurações da fábrica (como ligar um interruptor específico) necessárias para alcançar o local. Terceiro, se a IA tentar uma chave e ela não funcionar, o GapForge lembra desse fracasso. Ele diz à IA: "Não tente isso de novo; tente algo diferente", e a envia de volta com um plano melhor. Esse ciclo se repete, lentamente, mas com consistência, iluminando cada canto escuro.

Os resultados foram impressionantes. Não apenas o GapForge cobriu mais terreno do que outras oito técnicas de alto nível, como também encontrou 12 bugs do mundo real que estavam escondidos nas sombras. Estes incluíram 8 crashes (onde o compilador simplesmente desistiu e parou) e 4 miscompilations (onde o compilador construiu silenciosamente um programa quebrado que parecia perfeito). Os pesquisadores mostraram que cada parte do processo do GapForge era importante; se eles removessem a "leitura do mapa", a "adivinhação da chave" ou o "aprendizado com o erro", os resultados seriam significativamente piores. Enquanto outros métodos estavam ocupados gerando milhares de programas de teste, o GapForge gerou menos, porém muito mais inteligentes, provando que, no mundo do teste de software, qualidade e direção costumam vencer a quantidade bruta.

Resumo Técnico: GapForge

Declaração do Problema

As bases de código de compiladores modernos, como o GCC e o LLVM, são caracterizadas por uma escala e complexidade imensas, tornando difícil alcançar uma cobertura de código abrangente. As técnicas existentes de geração de testes — que variam desde métodos auxiliados por gramática e baseados em mutação até abordagens recentes de Grandes Modelos de Linguagem (LLMs) — operam primariamente de uma maneira "direcionada ao programa". Elas focam em gerar entradas diversas ou disparar bugs sem modelar explicitamente quais regiões específicas do compilador elas exercitam. Consequentemente, esses métodos tendem a exercitar repetidamente caminhos de "hotspot" frequentemente acionados, deixando lacunas substanciais de cobertura de "cauda longa" em arquivos subtestados e regiões de borda difíceis de alcançar. Embora técnicas de caixa branca como o WhiteFox tenham tentado abordar isso resumindo o código de otimização, elas frequentemente dependem de um sumarização grosseira ao nível de arquivo, que falha em fornecer a orientação detalhada necessária para alcançar regiões não cobertas específicas, particularmente aquelas que exigem opções de compilação ou estruturas de programa específicas.

Metodologia: GapForge

O GapForge é uma técnica de geração de testes de compilador baseada em LLM e direcionada, projetada para melhorar sistematicamente a cobertura do código-fonte através do raciocínio sobre lacunas de cobertura. Diferente de fuzzers gerais, o GapForge trata regiões de código não cobertas como alvos explícitos e itera através de um processo de três etapas para gerar programas de teste que exercitem essas lacunas específicas.

1. Seleção de Alvo Direcionada pela Cobertura

Para abordar o potencial de cobertura desigual entre milhares de arquivos de origem, o GapForge emprega um mecanismo de seleção probabilístico em vez de amostragem aleatória.

Pontuação de Exploração: Cada arquivo $f$ recebe uma pontuação $S_f = L_f \times (1 - C_f)^2$ , onde $L_f$ é a contagem de linhas e $C_f$ é a razão de cobertura atual. O termo quadrático amplifica a prioridade de arquivos com baixa cobertura.
Probabilidade de Seleção: Para evitar que arquivos de alta pontuação dominem o processo de seleção indefinidamente, as pontuações são normalizadas e transformadas em uma probabilidade de seleção $P_f = 1 - (1 - W_f)^k$ . Esta transformação não linear garante que, embora arquivos de alto potencial sejam favorecidos, arquivos de menor potencial ainda recebam uma chance de serem selecionados, equilibrando exploração e explotação.

2. Sumarização Direcionada

Em vez de sumarizar um arquivo inteiro, o GapForge realiza uma análise detalhada em intervalos de linhas não cobertos específicos.

Pareamento de Contexto: Para cada região não coberta, o sistema a pareia com seu "contexto coberto" imediatamente envolvente (o código ao redor da lacuna).
Análise de Diferença de Caminho: Um LLM analisa o contraste entre o contexto coberto e o alvo não coberto. Ele infere:
- Papel Funcional: O propósito de alto nível do arquivo dentro do pipeline do compilador.
- Requisitos de Disparo: Estruturas de programa específicas (ex: tipos de dados, padrões de fluxo de controle) necessárias para direcionar a execução para o bloco não coberto.
- Opções de Compilação: Flags específicas (ex: -fsanitize, -fdump-ada-spec) necessárias para ativar o caminho de código.
Saída: Este processo gera "Requisitos de Alvo" estruturados que servem como instruções precisas para a próxima etapa de geração.

3. Síntese de Prompt com Reflexão de Falha

O GapForge sintetiza um prompt estruturado para o LLM de geração de testes integrando três componentes:

Restrições Gerais: Regras que garantem que os programas gerados sejam válidos, determinísticos e estruturalmente complexos o suficiente para disparar caminhos profundos do compilador.
Requisitos de Alvo: Os objetivos e restrições específicos derivados da etapa de sumarização direcionada.
Reflexão de Falha: Um log por arquivo de prompts que falharam anteriormente (aqueles que resultaram em erros de compilação ou não cobriram novas regiões). O sistema recupera um caso de falha recente e instrui o LLM a evitar programas estruturalmente similares, criando um loop de refinamento iterativo que direciona a geração para longe de estratégias improdutivas.

Principais Contribuições

Framework GapForge: Uma técnica baseada em LLM que visa explicitamente lacunas de cobertura através de um fluxo de trabalho de três etapas: seleção de arquivo direcionada pela cobertura, análise de região detalhada (combinando código não coberto com contexto coberto) e síntese de prompt consciente de falhas.
Raciocínio de Grão Fino: Diferente de abordagens anteriores de caixa branca que resumem arquivos de forma holística, o GapForge infere requisitos de disparo específicos (estruturas de programa e opções de compilação) para blocos básicos não cobertos individuais.
Validação Empírica: Experimentos extensos no GCC 14.3.0 e LLVM 19.1.0 demonstrando melhorias significativas sobre os estados da arte de referência.
Reprodutibilidade: Um pacote público contendo o código-fonte e os dados da técnica.

Resultados Experimentais

Os autores avaliaram o GapForge contra oito técnicas de estado da arte (incluindo Csmith, WhiteFox, LegoFuzz e Fuzz4All) no GCC e LLVM durante um período de 72 horas.

Melhoria de Cobertura: O GapForge alcançou 68,13% de cobertura nos módulos principais do GCC e 69,11% nos módulos principais do LLVM. Isso superou a técnica de caixa branca anterior de estado da arte (WhiteFox) ao cobrir mais 24.736 linhas no GCC e 19.798 linhas no LLVM.
Ganhos Incrementais: O GapForge melhorou as próprias suítes de teste oficiais dos compiladores ao adicionar 3.452 novas linhas cobertas no GCC e 531 no LLVM, enquanto várias bases de referência adicionaram zero novas linhas às suítes oficiais.
Eficiência: O GapForge alcançou estes resultados com consumo significativamente menor de tokens (976K tokens para GCC) comparado ao WhiteFox (2.30M tokens) e LegoFuzz (3.63M tokens).
Descoberta de Bugs: A técnica descobriu 12 falhas reais de compilador (5 no GCC, 7 no LLVM), incluindo 8 crashes e 4 erros de má compilação (miscompilations).
Estudos de Ablação: Remover qualquer um dos três componentes principais (seleção de alvo, sumarização direcionada ou reflexão de falha) resultou em uma degradação mensurável de desempenho, confirmando a necessidade de cada módulo. Especificamente, a ausência de sumarização direcionada ou de recomendações de opções de compilação causou as quedas mais significativas na cobertura.

Significância

O artigo postula que o GapForge aborda uma limitação crítica no teste de compiladores atual: a incapacidade das técnicas existentes de alcançar sistematicamente lacunas de cobertura de "cauda longa". Ao mudar de uma abordagem direcionada ao programa para uma abordagem direcionada à lacuna de cobertura, o GapForge fornece um mecanismo para raciocinar explicitamente sobre como alcançar regiões de código não testadas específicas. Os resultados sugerem que combinar feedback de cobertura com raciocínio de LLM de grão fino permite um teste mais eficiente e eficaz de sistemas de software complexos e de grande escala como compiladores, levando ultimamente a uma maior confiabilidade e à descoberta de defeitos sutis que permanecem ocultos aos métodos de fuzzing tradicionais.