• 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 코드를 컴파일하기 위한 기반을 구축하고 있음

댓글과 토론