러스트 컴파일러 전체를 C로 번역한 ‘크러스트씨’ 공개

rustc를 통째로 C로 번역했다

• ‘crustc’는 동작하는 Rust 컴파일러를 C 코드 형태로 빌드할 수 있게 만든 데모임

  • GCC와 GNU make로 빌드하면 Rust 컴파일러가 나옴
  • 이 컴파일러는 core, alloc, std 같은 Rust 표준 구성 요소도 컴파일할 수 있다고 설명함
  • 저장소 자체는 새 툴체인 ‘cilly’의 쇼케이스에 가까움

• 작성자는 지난 3년간 Rust를 C로 컴파일하는 작업을 해왔고, 이번이 14번째 시도라고 밝힘

  • 이전에는 rustc_codegen_clr 같은 공개 시도도 있었고, 비공개 실험도 많았다고 함
  • cilly는 Rust 코드 생성 라이브러리이자 rustc 백엔드 플러그인으로 동작함
  • 즉 사용자는 특정 타깃에 어떤 C 컴파일러를 쓸지만 정하면, cilly가 Rust를 C로 바꿔 그 컴파일러에 넘기는 구조임

이상한 C 컴파일러까지 맞춰주는 방식

• cilly의 핵심 아이디어는 대상 C 컴파일러에 맞춰 코드를 생성하는 것임

  • 작성자는 예시로 “이상한 운영체제의 이상한 C 컴파일러”까지 언급함
  • 타입 레이아웃, 크기, 정렬, 문자 인코딩, 정수 표현 같은 걸 가정하지 않고 질의함
  • 가능한 한 ANSI C 밖의 가정을 피하고, 필요하면 런타임 assert나 문서화로 처리한다고 함

• 이를 위해 ‘증인 프로그램’을 생성해 대상 컴파일러와 플랫폼의 성질을 확인함

  • 예를 들어 포인터 왕복 변환, CHAR_BIT 값, 2의 보수 정수 표현 같은 현실적인 가정들을 검사하는 식
  • 그래서 생성된 C 코드는 이식 가능한 범용 C라기보다, 특정 컴파일러와 특정 플랫폼에 맞춘 C에 가까움
  • ARM64용으로 생성한 C를 그대로 RISC-V 32비트에서 돌리는 식은 안 되고, RISC-V용으로 다시 생성해야 함

• 네트워크 투명성도 꽤 특이한 부분임

  • cilly는 TCP 너머의 C 컴파일러와 통신할 수 있음
  • 정상적인 리눅스 머신에서 rustc를 돌리고, 특이한 운영체제 쪽에는 작은 C 서버만 띄워서 컴파일을 맡기는 방식이 가능함
  • 작성자는 실제로 ARM64 리눅스에서 rustc를 돌리면서 x86 Plan 9 가상머신용 작은 Rust 프로그램을 컴파일해봤다고 함

sequenceDiagram
    participant 개발자
    participant 러스트컴파일러
    participant 실리
    participant 원격C컴파일러
    participant 특이한플랫폼
    개발자->>러스트컴파일러: Rust 코드 빌드 요청
    러스트컴파일러->>실리: C 코드 생성 백엔드 호출
    실리->>원격C컴파일러: 플랫폼 특성 확인용 증인 프로그램 전송
    원격C컴파일러-->>실리: 타입 크기와 ABI 정보 반환
    실리->>원격C컴파일러: 대상 플랫폼용 C 코드 전달
    원격C컴파일러->>특이한플랫폼: 실행 가능한 결과물 생성

아직은 거칠지만, 방향은 선명함

• 이 프로젝트가 노리는 문제는 Rust의 오래된 약점 중 하나임

  • 어떤 프로젝트가 C에서 Rust로 옮겨가면 “그럼 Plan 9 같은 플랫폼은?”이라는 반론이 늘 나옴
  • LLVM이나 GCC가 없는 오래된 하드웨어, obscure 플랫폼은 Rust 지원에서 밀리기 쉬움
  • cilly의 목표는 C 컴파일러만 있는 곳에도 Rust를 가져가는 것임

• 다만 지금 공개된 건 안정적인 제품이 아니라 데모에 가까움

  • 빌드에는 특정 nightly Rust, LLVM 라이브러리, GCC, GNU make가 필요함
  • 최적화는 켜지 말라고 권장함. 최적화 관련 버그를 추적 중이고, 큰 Rust 파일에서 빌드가 막힐 수 있다고 함
  • 빌드된 디렉터리 안에서 실행하면 경로 정규화 문제로 crash가 날 수 있고, 다른 위치에서는 괜찮다는 이상한 제약도 있음

• ABI 호환성도 ‘대부분’이라는 단서가 붙음

  • 일반 rustc가 만든 코드와 대체로 ABI 호환이지만, 일부 플랫폼은 Rust ABI를 C로 표현하기 어렵다고 함
  • 예를 들어 ARM64에서는 작은 구조체 반환에서 sret 포인터가 C 컴파일러가 고르는 방식과 맞지 않는 문제가 있음
  • 이건 단순 번역기가 아니라 실제 컴파일러 백엔드가 얼마나 많은 플랫폼 디테일과 싸워야 하는지 보여주는 대목임

기술 맥락

• cilly가 흥미로운 이유는 Rust의 프론트엔드와 분석 능력은 그대로 쓰면서, 마지막 코드 생성 경로를 C로 바꾸려 한다는 점이에요. LLVM이 없는 플랫폼에서도 C 컴파일러는 있는 경우가 많기 때문에, C를 중간 목적지처럼 쓰는 전략이 나오는 거예요.

• 그런데 C로 내보낸다고 자동으로 이식성이 생기지는 않아요. C의 타입 크기, 정렬, 구조체 반환 규칙, 문자 인코딩은 컴파일러와 플랫폼마다 달라질 수 있거든요. 그래서 cilly는 증인 프로그램을 만들어 직접 물어보고, 그 결과에 맞춰 코드를 생성해요.

• 네트워크로 C 컴파일러와 통신하는 설계도 부트스트랩 문제를 겨냥해요. 특이한 운영체제 위에서 rustc 전체를 돌리기 어렵다면, 강한 머신에서 rustc를 실행하고 대상 시스템에는 작은 C 컴파일 서버만 두는 식으로 우회할 수 있어요.

• 가장 큰 트레이드오프는 생성된 C가 범용 산출물이 아니라는 점이에요. 특정 플랫폼의 ABI와 컴파일러 성질에 맞춰 나온 코드라서, 다른 아키텍처에 그대로 들고 가는 방식은 어렵지만, 대신 정말 이상한 타깃까지 맞출 여지를 얻어요.