Avances hacia compilar Linux con gccrs

• gccrs, el frontend de Rust para GCC, probó crates del kernel de Linux durante el primer semestre de 2026, corrigió problemas de manejo de atributos, resolución de nombres y gestión de recursos, y ahora se centra en implementar la semántica de ejecución correcta del código del kernel
• Para aprovechar arquitecturas que LLVM no soporta y el ecosistema existente de plugins de GCC, se necesita un compilador de Rust basado en GCC, que además puede dar a las distribuciones de Linux más opciones de toolchain
• La generación correcta de código requiere análisis dinámico de drop flags según el flujo de control; si esto falta, MutexGuard puede no liberar el bloqueo y provocar fallas de sincronización o interbloqueos
• Al compilar crates reales del kernel salieron a la luz una estructura de resolución de nombres que manejaba mal los tres espacios de nombres de Rust, el orden de procesamiento de #[cfg()] y problemas de metadatos de crate que omitían módulos anidados, lo que llevó a una gran refactorización
• Hubo avances en programas no_core y en el soporte de core y compiler_builtins, pero para compilar completamente el kernel aún se necesita soporte para alloc y semántica de ejecución precisa, además de revisión y coordinación para integrarlo upstream en GCC

---

Por qué tomaron al kernel de Linux como caso de prueba

• gccrs es un proyecto que desarrolla un frontend de Rust para GCC, y durante el primer semestre de 2026 se enfocó en compilar el kernel de Linux
  • Al probar crates del kernel encontraron y corrigieron problemas de manejo de atributos, resolución de nombres y gestión de recursos
  • Hoy todavía solo puede manejar programas independientes sencillos, pero las pruebas con código del kernel también impulsan avances en la generación correcta de código para otros programas en Rust
  • El avance quedó registrado en los reportes semanales y reportes mensuales del proyecto
• Actualmente, el código Rust del kernel de Linux debe usar rustc basado en LLVM
  • También está en desarrollo rust_codegen_gcc, un experimento para usar GCC como backend de rustc
  • Una alternativa basada en GCC es necesaria para soportar arquitecturas que LLVM no cubre e integrarse con el ecosistema existente de plugins de GCC
  • A medida que madura la integración de Rust en el kernel, las distribuciones de Linux están poniendo como prioridad la flexibilidad del toolchain y la disponibilidad de un compilador basado en GCC

Hitos definidos por capacidades, no por versiones de GCC

• El equipo de gccrs, en su reporte de marzo de 2026, reorganizó su trabajo en tres hitos basados en capacidades en lugar de apuntar a una versión específica de GCC
  • Compilador de Rust para embebidos: compila programas no_std que dependen solo de core
  • Compilador Rust for Linux: soporta core y ciertos crates usados por el kernel
  • Compilador de propósito general: maneja aplicaciones Rust más amplias fuera del entorno del kernel
• El primer hito aún no está completo, pero ya está muy cerca, y también empezó el trabajo del hito Rust for Linux
• En marzo de 2026 se añadió soporte para el crate de bajo nivel compiler_builtins, necesario para el build del kernel, y se concentraron en resolver problemas del crate ffi del kernel
• Zhi Heng se unió en mayo de 2026 mediante una pasantía de Open Source Security
  • Corrigió bugs que aparecían cuando gccrs compilaba crates del kernel
  • Armó pruebas de integración continua para evitar regresiones
• No basta con que el código Rust se procese sin fallar; el código generado también tiene que comportarse correctamente
  • Como el Rust idiomático usa más semántica de destructores que C, la implementación de Drop es clave para generar código correcto

Infraestructura de Drop para liberar recursos correctamente

• Rust gestiona recursos con el modelo RAII, donde la adquisición del recurso ocurre en la inicialización, y cuando un valor sale de alcance el compilador llama automáticamente al destructor definido en el trait Drop
• El estado de inicialización de una variable puede cambiar según el flujo de control dentro de una función
  • Si un valor se mueve de forma condicional o solo se inicializa parcialmente, no se puede destruir incondicionalmente al final del alcance
  • El frontend debe analizar el grafo de flujo de control, generar un drop flag dinámico —una variable booleana que registra en tiempo de ejecución si hace falta destruir un valor— y pasarlo al backend de GCC
• La implementación inicial de Drop en gccrs no tenía este análisis, así que algunas llamadas a Drop::drop() faltaban o se generaban mal
• En el kernel de Linux, omitir llamadas a Drop puede causar fallas graves en tiempo de ejecución, como fugas de memoria y recursos del sistema no liberados
  • Cuando se adquiere un bloqueo, la API de Rust for Linux devuelve un MutexGuard
  • La implementación de Drop de ese guard se encarga de liberar el bloqueo
  • Sin llamadas correctas a Drop, el bloqueo puede quedar retenido incluso cuando el guard sale de alcance, provocando fallas de sincronización o interbloqueos
• Janet Chien, participante de GSoC, se incorporó en mayo de 2026 para enfocarse en construir la infraestructura de Drop en gccrs

Reescritura de la resolución de nombres para ajustarse a los espacios de nombres de Rust

• Las pruebas con la biblioteca estándar y con crates del kernel revelaron bugs fundamentales de resolución de nombres en gccrs
  • El proyecto ya conocía varios de estos problemas y venía mejorando la resolución de nombres por separado desde 2023
• Rust distingue tres espacios de nombres
  • El espacio de nombres de valores incluye funciones y variables estáticas
  • El espacio de nombres de macros incluye macros
  • El espacio de nombres de tipos incluye structs, módulos y traits
• Para procesar rutas como crate::foo::bar, hay que determinar a qué espacio de nombres pertenece cada segmento identificador
• gccrs antes resolvía toda la ruta dentro de un solo espacio de nombres, según el tipo de elemento que buscaba al final
  • Si buscaba una función, resolvía todos los segmentos de la ruta en el espacio de nombres de valores
  • Pero como los módulos y los imports públicos están en el espacio de nombres de tipos, primero hay que seguir la estructura de módulos en ese espacio para llegar a la función
• Corregir esto exigió reescribir estructuras de datos internas y refactorizar implementaciones de visitantes por todo el código
  • En mayo de 2026 ya pudo resolver correctamente imports profundamente anidados del crate core
  • Al insertar módulos e imports en el espacio de nombres de tipos, el comportamiento se acercó más al de rustc

Mejoras en atributos condicionales y opciones del compilador

• Durante la compilación de crates del kernel también salieron a la luz problemas de manejo de atributos del compilador y de metadatos de crate en gccrs
• Rust usa atributos como #[cfg()] para compilación condicional
• Pierre-Emmanuel Patry rehízo en febrero de 2026 el pipeline de procesamiento de atributos
  • Separó en dos etapas el pase del compilador que elimina elementos excluidos por atributos cfg
  • Algunas funciones inestables del kernel dependen de expansión de macros o de atributos condicionales
  • Esos atributos deben eliminarse antes del pase principal de validación de atributos para evitar errores de compilación durante la validación
• En marzo de 2026 se añadió la opción -frust-crate-attr, equivalente a -Zcrate-attr de rustc
  • Permite que el sistema de build inyecte atributos durante la invocación del compilador sin modificar los archivos fuente originales
  • Es útil para pasar #![no_core], necesario para compilar código sin la biblioteca estándar core
  • Los desarrolladores que hacen fuzzing del compilador para encontrar bugs en casos límite también usan esta función

Metadatos faltantes descubiertos con código real del kernel

• Los crates de Rust normalmente exportan metadatos dentro de archivos .rlib para transmitir su API pública a otros crates
• Al enlazar los crates Rust del kernel se confirmó que algunos módulos y exports faltaban en los metadatos generados
  • gccrs omitía exports de módulos anidados durante la generación de metadatos
  • Como resultado, no se podían resolver dependencias externas
• Las pruebas existentes de metadatos usaban estructuras de módulos planas y no detectaron este problema; el bug solo salió a la luz al compilar código real
• Para poder enlazar el árbol de dependencias del kernel con el toolchain de GNU, empezaron una gran refactorización del sistema de procesamiento de metadatos

Alcance actual del soporte y limitaciones del upstream de GCC

• Actualmente gccrs puede manejar con éxito programas no_core independientes
• También hubo avances importantes en el manejo del crate core y en la implementación de compiler_builtins, pero el trabajo para compilar completamente las abstracciones Rust complejas del kernel sigue en curso
  • Puede analizar sintácticamente el código del kernel
  • El foco actual está en implementar con precisión la semántica de ejecución
• Además de los desafíos técnicos, también deben superar las limitaciones organizativas del toolchain GNU
  • Es muy grande la tarea de integrar en GCC un frontend para un lenguaje nuevo que cambia con rapidez
  • Algunos conjuntos grandes de parches incluso excedieron la limitada capacidad de revisión del upstream de GCC
  • La situación ha mejorado a medida que se estabiliza la estructura del frontend
• Recientemente, dos desarrolladores de gccrs fueron promovidos a maintainers de GCC
  • Ahora pueden preparar actualizaciones en su propio árbol y luego integrarlas de una sola vez

Soporte para alloc y próximas presentaciones

• Enes Çevik, participante de GSoC, se unió en mayo de 2026 para implementar soporte del crate alloc
• alloc se encarga de tipos de asignación dinámica de memoria como Box, Rc y Vec
  • Aunque el desarrollo del kernel evita varias abstracciones de la biblioteca estándar, algunas abstracciones clave del kernel en Rust dependen de tipos con asignación
  • Por eso, el soporte de alloc es un requisito indispensable para el hito Rust for Linux
• Patry y Arthur Cohen planean presentar “Compiling the Linux kernel with gccrs” más adelante en 2026 en RustConf en Montreal y EuroRust en Barcelona
• Al ir implementando una por una las funciones que exige el código del kernel, están sentando las bases para compilar con GCC el código Rust del ecosistema del kernel de Linux