▲

GN⁺: GCC 기반 Rust 컴파일러 개발 진전

 (lwn.net)
2P by neo 11달전 | favorite | 댓글 1개

GCC 기반 Rust 컴파일러 개발 진행 상황

  • GCC 기반 Rust 컴파일러 프로젝트인 gccrs는 2014년에 시작되어 GNU Compiler Collection(GCC) 내에서 Rust 컴파일러를 구현하는 것을 목표로 함.
  • gccrs의 목표는 GCC 13 릴리스에 포함되는 것이었으나, 이는 달성되지 않았고 현재는 GCC 14(2024년 중반 릴리스 예상)에 포함될 것을 목표로 함.
  • gccrs는 Rust 버전 1.49를 대상으로 하며, 이는 const generics이 도입되기 전의 마지막 버전임.
  • gccrs 프로젝트의 중요한 원칙 중 하나는 Rust의 "superset"을 만들지 않고, rustc의 출력을 그대로 복제하는 것임.
  • Rust 표준 라이브러리는 여러 "crates"로 구성되어 있으며, gccrs는 이 중 core와 alloc crate의 컴파일을 지원하는 데 집중하고 있음.
  • gccrs는 현재 여러 기능 부족으로 인해 이러한 crates를 컴파일할 수 없으며, borrow checker의 부재와 GCC에서 지원하지 않는 LLVM intrinsics의 부족이 문제임.

GCC 생태계의 이점 활용

  • gccrs 개발의 주요 이유 중 하나는 GCC의 보안 플러그인을 활용할 수 있게 하는 것임.
  • gccrs는 이미 Sega Dreamcast 홈브루 커뮤니티에서 사용되고 있으며, GCC 플러그인을 사용하여 unsafe Rust 코드의 정적 분석을 수행할 수 있음.
  • gccrs 노력을 통해 Rust 명세에 추가 기능을 기여할 수 있었으며, Rust의 공식 명세 작성 작업에 참여하고자 함.

개발 중인 기능들

  • gccrs는 여전히 많은 핵심 기능이 누락되어 있으며, async/await, GCC에서 부재한 LLVM intrinsics, format_args!() 매크로 등이 포함됨.
  • Polonius 프로젝트는 rustc의 현재 borrow checker의 단점을 해결하기 위해 다른 알고리즘으로 참조 수명을 계산하는 borrow checker를 구현함.
  • format_args!() 매크로 작업이 시작되었으며, 이는 다른 문자열 포맷팅 매크로에 전달되는 인수를 구성하는 데 필요함.

rustc_codegen_gcc

  • rustc_codegen_gcc는 gccrs보다 더 성숙하고 범위가 제한된 다른 GCC 기반 Rust 프로젝트임.
  • rustc_codegen_gcc는 libgccjit 라이브러리를 사용하여 rustc의 LLVM 백엔드 API에 연결하며, rustc와 GCC의 뒤늦은 단계에서 컴파일을 수행함.
  • 2023년 10월 기준으로 rustc_codegen_gcc는 추가 패치 없이 Rust for Linux를 컴파일할 수 있음.

Rust for Linux

  • Rust for Linux 프로젝트는 rustc 또는 rustc_codegen_gcc를 사용하여 커널용 Rust 코드를 빌드하는 방법에 대한 문서를 제공함.
  • gccrs는 Rust for Linux 지원을 목표로 하고 있으나, 현재 지원되는 rustc 버전과의 큰 차이로 인해 실현 가능성이 멀어 보임.

GN⁺의 의견

  • gccrs 프로젝트는 Rust 언어의 GCC 기반 컴파일러 구현을 목표로 하며, 이는 Rust 생태계에 다양성을 제공하고 GCC의 보안 플러그인과 같은 기존 도구를 활용할 수 있는 잠재력을 가짐.
  • gccrs가 Rust 표준 라이브러리의 핵심 부분을 아직 컴파일할 수 없는 상황이지만, 이미 Sega Dreamcast 홈브루 커뮤니티에서 실제 사용 사례를 찾을 수 있음은 주목할 만함.
  • 본 기사는 Rust 언어의 다양한 컴파일러 구현과 그에 따른 생태계 확장 가능성에 대한 흥미로운 통찰을 제공함.
▲
neo 11달전  [-]
Hacker News 의견

  • 첫 번째 댓글 요약:

    • 기사에서 gccrs 개발 동기에 대한 주장이 약하다고 느낌.
    • gccrs가 GCC의 보안 플러그인을 활용하기 위해 개발되고 있음.
    • 리눅스 커널에 러스트 지원을 추가하는 'Rust for Linux' 이니셔티브가 또 다른 이유임.
    • 리눅스 커널을 GNU 툴체인만으로 컴파일하길 원하는 커널 개발자들이 많아서 중요한 동기임.
    • GCC를 백엔드로 사용하는 이유는 설명되지만, 왜 중복된 프론트엔드가 필요한지에 대한 설명은 부족함.
    • C++의 실수에서 배워야 하며, 다양한 프론트엔드는 플랫폼 간 개발을 어렵게 만듦.
    • gccrs가 'GNU Rust'가 되지 않도록 주의를 기울이고 있으며, rustc의 출력을 복제하려고 함.

  • 두 번째 댓글 요약:

    • 러스트에는 언어 표준이 필요함.
    • 많은 조직과 산업이 표준이 없으면 러스트를 채택하지 않을 것임.
    • C, C++, C#, 자바스크립트(ECMAScript)와 같은 다른 언어들은 모두 표준을 가지고 있음.

  • 세 번째 댓글 요약:

    • GCC-RS에 대한 부정적인 반응에 놀람.
    • 언어가 여러 구현을 가지고 있지 않다면, 그 언어는 불완전한 것임.

  • 네 번째 댓글 요약:

    • gccrs가 LLVM이 지원하지 않는 아키텍처들에 대한 러스트 지원을 가능하게 할 것임.

  • 다섯 번째 댓글 요약:

    • gccrs가 rustc의 버그와 특이점까지 복제하려는 것은 실수라고 생각함.
    • 러스트에는 공식적인 사양이 없으며, 단일 참조 구현만으로 문서화하는 것은 장기적인 약점임.
    • 기존 코드가 모든 구현에서 작동하도록 하려는 것은 합리적이지만, 잘못된 결정과 버그를 영구화하는 문제가 있음.
    • 마이크로소프트는 오래된 프로그램이 계속 실행되도록 많은 노력을 기울임.
    • 러스트는 언어 개발 초기에 이러한 부담을 지지 말아야 함.
    • 언어가 진화하려면 QA와 QC를 수용해야 함.
    • 강력한 표준을 가진 언어들은 이러한 믿음을 받아들임.

  • 여섯 번째 댓글 요약:

    • lwn.net 링크를 게시해줘서 구독 갱신을 상기시켜줌에 감사함.

  • 일곱 번째 댓글 요약:

    • 리눅스는 이미 clang을 사용하여 컴파일할 수 있음.
    • GNU '순수성'을 위해 이러한 중복된 노력을 개발하고 유지하는 것은 가치가 없어 보임.
답변달기