# gccrs로 Linux 컴파일을 향한 진전 > Clean Markdown view of GeekNews topic #32015. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=32015](https://news.hada.io/topic?id=32015) - GeekNews Markdown: [https://news.hada.io/topic/32015.md](https://news.hada.io/topic/32015.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-31T21:02:04+09:00 - Updated: 2026-07-31T21:02:04+09:00 - Original source: [lwn.net](https://lwn.net/SubscriberLink/1083202/f1ba926cd57ac5c5/) - Points: 1 - Comments: 0 ## Topic Body - GCC용 Rust 프런트엔드 **gccrs**는 2026년 상반기 Linux 커널 크레이트를 시험하며 속성 처리, 이름 해석, 자원 관리 문제를 수정했고, 이제 커널 코드의 정확한 실행 의미론 구현에 집중하고 있음 - LLVM이 지원하지 않는 아키텍처와 기존 **GCC 플러그인 생태계**를 활용하려면 GCC 기반 Rust 컴파일러가 필요하며, Linux 배포판에도 도구 체인 선택권을 제공할 수 있음 - 정확한 코드 생성에는 제어 흐름에 따른 **동적 drop flag 분석**이 필요하며, 이를 빠뜨리면 `MutexGuard`가 잠금을 해제하지 않아 동기화 실패나 교착 상태로 이어질 수 있음 - 실제 커널 크레이트를 컴파일하면서 Rust의 세 네임스페이스를 잘못 처리한 이름 해석 구조, `#[cfg()]` 처리 순서, 중첩 모듈을 누락한 **크레이트 메타데이터** 문제가 드러나 대규모 재작업이 진행됨 - `no_core` 프로그램과 `core`, `compiler_builtins` 지원은 진전됐지만, 완전한 커널 컴파일에는 **`alloc` 지원과 정확한 실행 의미론**이 더 필요하며 GCC 업스트림 통합을 위한 검토와 조율도 남아 있음 --- ### Linux 커널을 시험 대상으로 삼은 이유 - [gccrs](https://rust-gcc.github.io/)는 GCC용 **Rust 프런트엔드**를 개발하는 프로젝트로, 2026년 상반기에는 Linux 커널 컴파일에 집중함 - 커널 크레이트를 시험하면서 속성 처리, 이름 해석, 자원 관리 문제를 발견하고 수정함 - 현재는 단순한 독립 프로그램만 처리할 수 있지만, 커널 코드 시험은 다른 Rust 프로그램의 올바른 코드 생성에도 진전을 가져옴 - 진행 상황은 프로젝트의 [주간 보고서](https://github.com/Rust-GCC/Reporting/tree/main/2026)와 [월간 보고서](https://rust-gcc.github.io/#status-reports)에 기록됨 - 현재 Linux 커널의 Rust 코드는 LLVM 기반 `rustc`를 사용해야 함 - `rustc`에서 GCC를 백엔드로 사용하는 실험적 [rust_codegen_gcc](https://github.com/rust-lang/rustc_codegen_gcc#wip-libgccjit-codegen-backend-for-rust)도 개발 중임 - GCC 기반 대안은 LLVM이 대상으로 삼지 않는 아키텍처를 지원하고 기존 **GCC 플러그인 생태계**와 통합하는 데 필요함 - 커널의 Rust 통합이 성숙하면서 Linux 배포판은 도구 체인 유연성과 GCC 기반 컴파일러의 가용성을 우선 과제로 삼고 있음 ### GCC 버전 대신 역량으로 나눈 마일스톤 - gccrs 팀은 [2026년 3월 보고서](https://rust-gcc.github.io/2026/04/13/2026-03-monthly-report.html)에서 특정 GCC 버전을 목표로 삼는 대신 **세 가지 역량 기반 마일스톤**으로 작업 체계를 바꿈 - **임베디드 Rust 컴파일러**: `core`에만 의존하는 `no_std` 프로그램을 컴파일함 - **Rust for Linux 컴파일러**: `core`와 커널에서 사용하는 특정 크레이트를 지원함 - **범용 컴파일러**: 커널 환경을 넘어 더 폭넓은 Rust 애플리케이션을 처리함 - 첫 번째 마일스톤은 아직 완성되지 않았지만 거의 도달했으며, Rust for Linux 마일스톤 작업도 시작됨 - 2026년 3월에는 커널 빌드에 필요한 저수준 크레이트 [compiler_builtins](https://crates.io/crates/compiler_builtins) 지원을 추가하고 커널의 `ffi` 크레이트 문제 해결에 집중함 - Zhi Heng은 2026년 5월 [Open Source Security](https://opensrcsec.com/) 인턴십으로 합류함 - gccrs가 커널 크레이트를 컴파일할 때 발생하는 버그를 수정함 - 회귀를 막기 위한 **지속적 통합 테스트**를 구축함 - Rust 코드를 충돌 없이 처리하는 것만으로는 부족하며, 생성된 코드도 정확하게 동작해야 함 - 관용적인 Rust 코드는 C보다 소멸자 의미론을 더 많이 사용하므로 `Drop` 구현이 올바른 코드 생성의 핵심임 ### 정확한 자원 해제를 위한 Drop 인프라 - Rust는 자원 획득이 초기화인 **RAII** 모델로 자원을 관리하며, 값이 범위를 벗어나면 컴파일러가 [Drop trait](https://doc.rust-lang.org/std/ops/trait.Drop.html)에 정의된 소멸자를 자동 호출함 - 변수의 초기화 상태는 함수 내부의 제어 흐름에 따라 달라질 수 있음 - 값이 조건부로 이동되거나 일부만 초기화되면 범위 끝에서 무조건 제거할 수 없음 - 프런트엔드는 제어 흐름 그래프를 분석해 값의 제거 필요 여부를 실행 시간에 기록하는 불리언 변수인 **동적 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` 속성으로 제외된 항목을 제거하는 컴파일러 패스를 [두 단계로 분리](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=49aae3a1ae302dd979c503db8dee56c8c378838b)함 - 커널의 일부 불안정 기능은 매크로 확장이나 조건부 속성에 의존함 - 이런 속성을 주 속성 검증 패스보다 먼저 제거해야 검증 과정에서 컴파일 오류가 발생하지 않음 - 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](https://doc.rust-lang.org/alloc/) 크레이트 지원을 구현하고 있음 - `alloc`은 `Box`, `Rc`, `Vec` 같은 **동적 메모리 할당 타입**을 담당함 - 커널 개발은 여러 표준 라이브러리 추상화를 피하지만, 일부 핵심 Rust 커널 추상화는 할당 타입에 의존함 - 따라서 `alloc` 지원은 Rust for Linux 마일스톤의 필수 조건임 - Patry와 Arthur Cohen은 2026년 후반 Montreal의 [RustConf](https://rustconf.com/)와 Barcelona의 [EuroRust](https://eurorust.eu/)에서 “**Compiling the Linux kernel with gccrs**” 발표를 진행할 계획임 - 커널 코드가 요구하는 기능을 차례로 구현하면서 GCC로 Linux 커널 생태계의 Rust 코드를 컴파일하기 위한 기반을 구축하고 있음 ## Comments _No public comments on this page._