Avanços rumo à compilação do Linux com gccrs

• O gccrs, front-end de Rust para o GCC, testou crates do kernel Linux no primeiro semestre de 2026, corrigindo problemas de processamento de atributos, resolução de nomes e gerenciamento de recursos, e agora se concentra em implementar corretamente a semântica de execução do código do kernel
• Um compilador Rust baseado no GCC é necessário para aproveitar arquiteturas não compatíveis com LLVM e o ecossistema existente de plugins do GCC, além de poder oferecer às distribuições Linux mais opções de toolchain
• A geração correta de código exige análise dinâmica de drop flags de acordo com o fluxo de controle; se isso for omitido, um MutexGuard pode não liberar o bloqueio, levando a falhas de sincronização ou deadlocks
• Ao compilar crates reais do kernel, surgiram problemas que levaram a um grande retrabalho: uma estrutura de resolução de nomes que tratava incorretamente os três namespaces do Rust, a ordem de processamento de #[cfg()] e metadados de crate que omitiam módulos aninhados
• Embora tenha havido avanços no suporte a programas no_core e a core e compiler_builtins, a compilação completa do kernel ainda exige suporte a alloc e semântica de execução correta, além de revisão e coordenação para integração ao upstream do GCC

---

Por que usar o kernel Linux como alvo de teste

• gccrs é um projeto que desenvolve um front-end de Rust para o GCC e, no primeiro semestre de 2026, concentrou-se na compilação do kernel Linux
  • Ao testar crates do kernel, encontrou e corrigiu problemas de processamento de atributos, resolução de nomes e gerenciamento de recursos
  • Atualmente ele só consegue lidar com programas independentes simples, mas testar código do kernel também traz avanços para a geração correta de código em outros programas Rust
  • O progresso é registrado nos relatórios semanais e relatórios mensais do projeto
• O código Rust do kernel Linux atualmente precisa usar o rustc baseado em LLVM
  • O rust_codegen_gcc, um experimento que usa o GCC como back-end no rustc, também está em desenvolvimento
  • Uma alternativa baseada no GCC é necessária para dar suporte a arquiteturas que o LLVM não tem como alvo e para se integrar ao ecossistema existente de plugins do GCC
  • À medida que a integração de Rust no kernel amadurece, distribuições Linux passam a priorizar a flexibilidade de toolchains e a disponibilidade de compiladores baseados no GCC

Marcos definidos por capacidades, não por versões do GCC

• No relatório de março de 2026, a equipe do gccrs mudou a organização do trabalho: em vez de mirar uma versão específica do GCC, passou a usar três marcos baseados em capacidades
  • Compilador Rust embarcado: compila programas no_std que dependem apenas de core
  • Compilador Rust for Linux: dá suporte a core e a crates específicos usados pelo kernel
  • Compilador de uso geral: lida com uma gama mais ampla de aplicações Rust além do ambiente do kernel
• O primeiro marco ainda não foi concluído, mas está quase lá, e o trabalho no marco Rust for Linux também começou
• Em março de 2026, foi adicionado suporte ao crate de baixo nível compiler_builtins, necessário para a build do kernel, e o foco passou a ser resolver problemas no crate ffi do kernel
• Zhi Heng entrou em maio de 2026 por meio de um estágio na Open Source Security
  • Corrigiu bugs que ocorriam quando o gccrs compilava crates do kernel
  • Criou testes de integração contínua para evitar regressões
• Processar código Rust sem falhas não é suficiente; o código gerado também precisa funcionar corretamente
  • Código Rust idiomático usa semântica de destrutores mais do que C, então implementações de Drop são centrais para a geração correta de código

Infraestrutura de Drop para liberação correta de recursos

• Rust gerencia recursos com o modelo RAII, em que a aquisição de recursos é inicialização, e o compilador chama automaticamente o destrutor definido no trait Drop quando um valor sai de escopo
• O estado de inicialização de uma variável pode variar conforme o fluxo de controle dentro de uma função
  • Se um valor for movido condicionalmente ou inicializado apenas parcialmente, ele não pode ser destruído incondicionalmente no fim do escopo
  • O front-end precisa analisar o grafo de fluxo de controle, criar drop flags dinâmicas — variáveis booleanas que registram em tempo de execução se um valor precisa ser destruído — e então passá-las ao back-end do GCC
• A implementação inicial de Drop no gccrs não tinha essa análise, fazendo com que algumas chamadas a Drop::drop() fossem omitidas ou geradas incorretamente
• No kernel Linux, omitir chamadas a Drop pode levar a falhas graves em tempo de execução, como vazamentos de memória e não liberação de recursos do sistema
  • Ao adquirir um bloqueio, a API Rust for Linux retorna um MutexGuard
  • A implementação de Drop desse guard é responsável por liberar o bloqueio
  • Sem a chamada correta a Drop, o bloqueio permanece mesmo quando o guard sai de escopo, podendo causar falhas de sincronização ou deadlocks
• A participante do GSoC Janet Chien entrou em maio de 2026 e passou a se concentrar na construção da infraestrutura de Drop do gccrs

Reescrita da resolução de nomes para os namespaces do Rust

• Testes com a biblioteca padrão e crates do kernel revelaram bugs fundamentais de resolução de nomes no gccrs
  • O projeto já conhecia vários problemas e vinha aprimorando separadamente a resolução de nomes desde 2023
• Rust distingue três namespaces
  • O namespace de valores inclui funções e variáveis estáticas
  • O namespace de macros inclui macros
  • O namespace de tipos inclui structs, módulos e traits
• Para processar caminhos como crate::foo::bar, é preciso determinar a qual namespace pertence cada segmento identificador
• O gccrs existente resolvia todo o caminho em um único namespace, de acordo com o tipo do item buscado no fim
  • Ao procurar uma função, todos os segmentos do caminho eram resolvidos no namespace de valores
  • Porém módulos e imports públicos ficam no namespace de tipos; portanto, primeiro é preciso seguir a estrutura de módulos no namespace de tipos para então chegar à função
• Para corrigir isso, foi necessário reescrever estruturas internas de dados e refatorar implementações de visitors por todo o código
  • Em maio de 2026, o crate core passou a ter imports profundamente aninhados resolvidos corretamente
  • Ao inserir módulos e imports no namespace de tipos, o comportamento ficou mais próximo do rustc

Melhorias em atributos condicionais e opções do compilador

• A compilação de crates do kernel também expôs problemas no processamento de atributos do compilador e nos metadados de crates do gccrs
• Rust usa atributos como #[cfg()] para compilação condicional
• Pierre-Emmanuel Patry retrabalhou o pipeline de processamento de atributos em fevereiro de 2026
  • Separou em duas etapas o passe do compilador que remove itens excluídos por atributos cfg
  • Alguns recursos instáveis do kernel dependem de expansão de macros ou de atributos condicionais
  • Esses atributos precisam ser removidos antes do passe principal de validação de atributos para evitar erros de compilação durante a validação
• Em março de 2026, foi adicionada a opção -frust-crate-attr, equivalente ao -Zcrate-attr do rustc
  • Ela permite que o sistema de build injete atributos na chamada do compilador sem modificar os arquivos-fonte originais
  • É útil para passar #![no_core], necessário para compilar código sem a biblioteca padrão core
  • Desenvolvedores que fazem fuzzing do compilador para encontrar bugs em casos de borda também usam esse recurso

Metadados ausentes revelados por código real do kernel

• Crates Rust normalmente exportam metadados incluídos em arquivos .rlib para transmitir a API pública a outros crates
• Ao vincular crates Rust do kernel, foi constatado que alguns módulos e exports estavam ausentes nos metadados gerados
  • O gccrs omitia exports de módulos aninhados durante a geração de metadados
  • Como resultado, dependências externas não podiam ser resolvidas
• Os testes de metadados existentes usavam uma estrutura de módulos plana e não detectaram o problema; o bug só apareceu depois de compilar código real
• Começou um grande retrabalho do sistema de processamento de metadados para permitir que a árvore de dependências do kernel seja vinculada com a toolchain GNU

Escopo de suporte atual e restrições do upstream do GCC

• Atualmente, o gccrs consegue processar com sucesso programas independentes no_core
• O processamento do crate core e a implementação de compiler_builtins também avançaram bastante, mas o trabalho de compilar completamente as abstrações Rust complexas do kernel ainda está em andamento
  • O código do kernel pode ser analisado sintaticamente
  • O foco atual é implementar corretamente a semântica de tempo de execução
• Além dos desafios técnicos, também é preciso superar restrições organizacionais da toolchain GNU
  • O esforço para integrar ao GCC um novo front-end de linguagem que muda rapidamente é grande
  • Grandes conjuntos de patches às vezes excederam a capacidade limitada de revisão do upstream do GCC
  • A situação melhorou à medida que a estrutura do front-end se estabilizou
• Recentemente, dois desenvolvedores do gccrs foram promovidos a mantenedores do GCC
  • Com isso, eles podem preparar atualizações em sua própria árvore e depois incorporá-las de uma vez

Suporte a alloc e próximas apresentações

• O participante do GSoC Enes Çevik entrou em maio de 2026 e está implementando suporte ao crate alloc
• alloc é responsável por tipos com alocação dinâmica de memória, como Box, Rc e Vec
  • O desenvolvimento do kernel evita várias abstrações da biblioteca padrão, mas algumas abstrações Rust centrais do kernel dependem de tipos com alocação
  • Portanto, o suporte a alloc é requisito essencial para o marco Rust for Linux
• Patry e Arthur Cohen planejam apresentar “Compiling the Linux kernel with gccrs” na RustConf em Montreal e na EuroRust em Barcelona no segundo semestre de 2026
• Ao implementar, uma a uma, as funcionalidades exigidas pelo código do kernel, o projeto está construindo a base para compilar com o GCC o código Rust do ecossistema do kernel Linux