gccrsによるLinuxコンパイルへ前進

 (lwn.net)
1 ポイント 投稿者 GN⁺ 2 시간 전 | まだコメントはありません。 | WhatsAppで共有
  • GCC向けRustフロントエンド gccrs は、2026年前半にLinuxカーネルのクレートを試験対象として、属性処理、名前解決、リソース管理の問題を修正し、現在はカーネルコードの正確な実行意味論の実装に注力している
  • LLVMがサポートしないアーキテクチャや既存の GCCプラグインエコシステム を活用するには、GCCベースのRustコンパイラが必要であり、Linuxディストリビューションにもツールチェーンの選択肢を提供できる
  • 正確なコード生成には、制御フローに応じた 動的drop flag解析 が必要で、これが欠けると MutexGuard がロックを解除せず、同期不全やデッドロックにつながりうる
  • 実際のカーネルクレートをコンパイルする中で、Rustの3つの名前空間を誤って扱っていた名前解決の構造、#[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バージョンを目標にする代わりに、3つの能力ベースのマイルストーン に作業体制を切り替えた
    • 組み込み向け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は3つの名前空間を区別する
    • 値名前空間には関数と静的変数が属する
    • マクロ名前空間にはマクロが属する
    • 型名前空間には構造体、モジュール、traitが属する
  • crate::foo::bar のようなパスを処理するには、各識別子区間がどの名前空間に属するかを判定しなければならない
  • 以前のgccrsは、最終的に見つけたい項目の種類に合わせて、パス全体を1つの名前空間で解決していた
    • 関数を探すときは、すべてのパス区間を値名前空間で解決していた
    • しかしモジュールと公開importは型名前空間にあるため、関数に到達するにはまず型名前空間でモジュール構造をたどる必要がある
  • これを修正するには、内部データ構造を書き直し、コード全体のvisitor実装をリファクタリングする必要があった
    • 2026年5月には、core クレートの深く入れ子になったimportを正しく解決できるようになった
    • モジュールとimportを型名前空間に挿入することで、挙動は rustc により近づいた

条件付き属性とコンパイラオプションの改善

  • カーネルクレートのコンパイル過程で、gccrsの コンパイラ属性処理 とクレートメタデータの問題も明らかになった
  • Rustは #[cfg()] のような属性で条件付きコンパイルを行う
  • Pierre-Emmanuel Patryは2026年2月に属性処理パイプラインを作り直した
    • cfg 属性で除外された項目を削除するコンパイラパスを2段階に分離した
    • カーネルの一部の不安定機能はマクロ展開や条件付き属性に依存している
    • こうした属性は主属性検証パスより前に削除しないと、検証過程でコンパイルエラーが発生する
  • 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コードをコンパイルするための基盤を築いている

関連記事

まだコメントはありません。

まだコメントはありません。