gccrs로 Linux 컴파일을 향한 진전

 (lwn.net)
1P by GN⁺ | ★ favorite | 댓글과 토론
  • GCC용 Rust 프런트엔드 gccrs는 2026년 상반기 Linux 커널 크레이트를 시험하며 속성 처리, 이름 해석, 자원 관리 문제를 수정했고, 이제 커널 코드의 정확한 실행 의미론 구현에 집중하고 있음
  • LLVM이 지원하지 않는 아키텍처와 기존 GCC 플러그인 생태계를 활용하려면 GCC 기반 Rust 컴파일러가 필요하며, Linux 배포판에도 도구 체인 선택권을 제공할 수 있음
  • 정확한 코드 생성에는 제어 흐름에 따른 동적 drop flag 분석이 필요하며, 이를 빠뜨리면 MutexGuard가 잠금을 해제하지 않아 동기화 실패나 교착 상태로 이어질 수 있음
  • 실제 커널 크레이트를 컴파일하면서 Rust의 세 네임스페이스를 잘못 처리한 이름 해석 구조, #[cfg()] 처리 순서, 중첩 모듈을 누락한 크레이트 메타데이터 문제가 드러나 대규모 재작업이 진행됨
  • no_core 프로그램과 core, compiler_builtins 지원은 진전됐지만, 완전한 커널 컴파일에는 alloc 지원과 정확한 실행 의미론이 더 필요하며 GCC 업스트림 통합을 위한 검토와 조율도 남아 있음

Linux 커널을 시험 대상으로 삼은 이유

  • gccrs는 GCC용 Rust 프런트엔드를 개발하는 프로젝트로, 2026년 상반기에는 Linux 커널 컴파일에 집중함
    • 커널 크레이트를 시험하면서 속성 처리, 이름 해석, 자원 관리 문제를 발견하고 수정함
    • 현재는 단순한 독립 프로그램만 처리할 수 있지만, 커널 코드 시험은 다른 Rust 프로그램의 올바른 코드 생성에도 진전을 가져옴
    • 진행 상황은 프로젝트의 주간 보고서와 월간 보고서에 기록됨
  • 현재 Linux 커널의 Rust 코드는 LLVM 기반 rustc를 사용해야 함
    • rustc에서 GCC를 백엔드로 사용하는 실험적 rust_codegen_gcc도 개발 중임
    • GCC 기반 대안은 LLVM이 대상으로 삼지 않는 아키텍처를 지원하고 기존 GCC 플러그인 생태계와 통합하는 데 필요함
    • 커널의 Rust 통합이 성숙하면서 Linux 배포판은 도구 체인 유연성과 GCC 기반 컴파일러의 가용성을 우선 과제로 삼고 있음

GCC 버전 대신 역량으로 나눈 마일스톤

  • gccrs 팀은 2026년 3월 보고서에서 특정 GCC 버전을 목표로 삼는 대신 세 가지 역량 기반 마일스톤으로 작업 체계를 바꿈
    • 임베디드 Rust 컴파일러: core에만 의존하는 no_std 프로그램을 컴파일함
    • Rust for Linux 컴파일러: core와 커널에서 사용하는 특정 크레이트를 지원함
    • 범용 컴파일러: 커널 환경을 넘어 더 폭넓은 Rust 애플리케이션을 처리함
  • 첫 번째 마일스톤은 아직 완성되지 않았지만 거의 도달했으며, Rust for Linux 마일스톤 작업도 시작됨
  • 2026년 3월에는 커널 빌드에 필요한 저수준 크레이트 compiler_builtins 지원을 추가하고 커널의 ffi 크레이트 문제 해결에 집중함
  • Zhi Heng은 2026년 5월 Open Source Security 인턴십으로 합류함
    • gccrs가 커널 크레이트를 컴파일할 때 발생하는 버그를 수정함
    • 회귀를 막기 위한 지속적 통합 테스트를 구축함
  • Rust 코드를 충돌 없이 처리하는 것만으로는 부족하며, 생성된 코드도 정확하게 동작해야 함
    • 관용적인 Rust 코드는 C보다 소멸자 의미론을 더 많이 사용하므로 Drop 구현이 올바른 코드 생성의 핵심임

정확한 자원 해제를 위한 Drop 인프라

  • Rust는 자원 획득이 초기화인 RAII 모델로 자원을 관리하며, 값이 범위를 벗어나면 컴파일러가 Drop trait에 정의된 소멸자를 자동 호출함
  • 변수의 초기화 상태는 함수 내부의 제어 흐름에 따라 달라질 수 있음
    • 값이 조건부로 이동되거나 일부만 초기화되면 범위 끝에서 무조건 제거할 수 없음
    • 프런트엔드는 제어 흐름 그래프를 분석해 값의 제거 필요 여부를 실행 시간에 기록하는 불리언 변수인 동적 drop flag를 생성한 뒤 GCC 백엔드에 전달해야 함
  • 초기 gccrs Drop 구현에는 이 분석이 없어 일부 Drop::drop() 호출이 누락되거나 잘못 생성됨
  • Linux 커널에서 Drop 호출 누락은 메모리 누수와 시스템 자원 미반환 같은 심각한 실행 시간 장애로 이어짐
    • 잠금을 획득하면 Rust for Linux API는 MutexGuard를 반환함
    • 이 가드의 Drop 구현이 잠금 해제를 담당함
    • 올바른 Drop 호출이 없으면 가드가 범위를 벗어나도 잠금이 유지돼 동기화 실패나 교착 상태가 발생할 수 있음
  • GSoC 참가자 Janet Chien은 2026년 5월 합류해 gccrs의 Drop 인프라 구축에 집중함

Rust 네임스페이스에 맞춘 이름 해석 재작성

  • 표준 라이브러리와 커널 크레이트 시험에서 gccrs의 근본적인 이름 해석 버그가 드러남
    • 프로젝트는 여러 문제를 이미 알고 있었으며 2023년부터 이름 해석을 별도로 개선해 왔음
  • Rust는 세 가지 네임스페이스를 구분함
    • 값 네임스페이스에는 함수와 정적 변수가 속함
    • 매크로 네임스페이스에는 매크로가 속함
    • 타입 네임스페이스에는 구조체, 모듈, trait가 속함
  • crate::foo::bar 같은 경로를 처리하려면 각 식별자 구간이 어느 네임스페이스에 속하는지 판별해야 함
  • 기존 gccrs는 최종적으로 찾으려는 항목의 종류에 맞춰 전체 경로를 하나의 네임스페이스에서 해석함
    • 함수를 찾을 때는 모든 경로 구간을 값 네임스페이스에서 해석함
    • 하지만 모듈과 공개 import는 타입 네임스페이스에 있으므로, 먼저 타입 네임스페이스에서 모듈 구조를 따라가야 함수에 도달할 수 있음
  • 이를 바로잡으려면 내부 데이터 구조를 재작성하고 코드 전반의 방문자 구현을 리팩터링해야 했음
    • 2026년 5월에는 core 크레이트의 깊게 중첩된 import를 올바르게 해석할 수 있게 됨
    • 모듈과 import를 타입 네임스페이스에 삽입하면서 동작이 rustc에 더 가까워짐

조건부 속성과 컴파일러 옵션 개선

  • 커널 크레이트 컴파일 과정에서 gccrs의 컴파일러 속성 처리와 크레이트 메타데이터 문제도 드러남
  • Rust는 #[cfg()] 같은 속성으로 조건부 컴파일을 수행함
  • Pierre-Emmanuel Patry는 2026년 2월 속성 처리 파이프라인을 재작업함
    • cfg 속성으로 제외된 항목을 제거하는 컴파일러 패스를 두 단계로 분리함
    • 커널의 일부 불안정 기능은 매크로 확장이나 조건부 속성에 의존함
    • 이런 속성을 주 속성 검증 패스보다 먼저 제거해야 검증 과정에서 컴파일 오류가 발생하지 않음
  • 2026년 3월에는 rustc의 -Zcrate-attr에 해당하는 -frust-crate-attr 옵션을 추가함
    • 빌드 시스템이 원본 소스 파일을 수정하지 않고 컴파일러 호출 시 속성을 주입할 수 있음
    • 표준 core 라이브러리 없이 코드를 컴파일하는 데 필요한 #![no_core] 전달에 유용함
    • 경계 사례 버그를 찾기 위해 컴파일러를 퍼징하는 개발자들도 이 기능을 사용함

실제 커널 코드에서 드러난 메타데이터 누락

  • Rust 크레이트는 일반적으로 .rlib 파일에 포함된 메타데이터를 내보내 다른 크레이트에 공개 API를 전달함
  • 커널의 Rust 크레이트를 링크하는 과정에서 일부 모듈과 export가 생성된 메타데이터에서 빠진 사실이 확인됨
    • gccrs가 메타데이터 생성 중 중첩 모듈의 export를 누락함
    • 그 결과 외부 의존성을 해석할 수 없었음
  • 기존 메타데이터 테스트는 평평한 모듈 구조를 사용해 이 문제를 발견하지 못했으며, 실제 코드를 컴파일한 뒤에야 버그가 드러남
  • GNU 도구 체인으로 커널 의존성 트리를 링크할 수 있도록 메타데이터 처리 시스템을 대규모로 재작업하기 시작함

현재 지원 범위와 GCC 업스트림 제약

  • 현재 gccrs는 독립적인 no_core 프로그램을 성공적으로 처리할 수 있음
  • core 크레이트 처리와 compiler_builtins 구현도 상당히 진전됐지만, 커널의 복잡한 Rust 추상화를 완전히 컴파일하는 작업은 진행 중임
    • 커널 코드를 구문 분석할 수 있음
    • 현재 초점은 실행 시간 의미론을 정확히 구현하는 데 있음
  • 기술적 과제와 함께 GNU 도구 체인의 조직적 제약도 넘어야 함
    • 빠르게 변화하는 새 언어 프런트엔드 전체를 GCC에 통합하는 작업 규모가 큼
    • 대규모 패치 세트가 제한된 GCC 업스트림 검토 역량을 넘어서기도 했음
    • 프런트엔드 구조가 안정화되면서 상황은 개선됨
  • 최근 gccrs 개발자 2명이 GCC 메인테이너로 승격됨
    • 자체 트리에서 업데이트를 준비한 뒤 한꺼번에 반영할 수 있게 됨

alloc 지원과 향후 발표

  • GSoC 참가자 Enes Çevik은 2026년 5월 합류해 alloc 크레이트 지원을 구현하고 있음
  • alloc은 Box, Rc, Vec 같은 동적 메모리 할당 타입을 담당함
    • 커널 개발은 여러 표준 라이브러리 추상화를 피하지만, 일부 핵심 Rust 커널 추상화는 할당 타입에 의존함
    • 따라서 alloc 지원은 Rust for Linux 마일스톤의 필수 조건임
  • Patry와 Arthur Cohen은 2026년 후반 Montreal의 RustConf와 Barcelona의 EuroRust에서 “Compiling the Linux kernel with gccrs” 발표를 진행할 계획임
  • 커널 코드가 요구하는 기능을 차례로 구현하면서 GCC로 Linux 커널 생태계의 Rust 코드를 컴파일하기 위한 기반을 구축하고 있음

함께 보면 좋은 글 β