Google の開発者は、LLVM 用に独自の libc を開発することを提案しました

Googleの開発者の一人 上げた LLVM メーリング リストで、LLVM プロジェクトの一部としてのマルチプラットフォーム標準 C ライブラリ (Libc) の開発について説明します。 さまざまな理由から、Google は現在の libc (glibc、musl) に満足しておらず、LLVM の一部として開発することが提案されている新しい実装の開発に取り組んでいます。

LLVM の開発は、最近、Google のアセンブリ ツールを構築するための基礎として使用されています。 主なアイデアは、Google がすでに libc の開発を開始しているのであれば、そのシステムを LLVM の一部としてすぐに開発してはどうだろうか、というものです。LLVM はすでに C++ 用の独自の標準ライブラリ (Libc++) を提供していますが、C 用の同様の標準ライブラリはありません。 (libc)。

開発は段階的に進められ、徐々に機能が強化される予定だ。 最初のオプションは、アプリケーションとシステム Libc の間の層として設計することが提案されており、そこからまだ実装されていない機能が借用されます。 一定の機能レベルに達すると、新しい Libc をシステム Libc の完全な代替品として使用できます。 まず、x86-64 アーキテクチャ、Linux、および静的リンクのサポートを開始する予定です (動的ロード、リンク、および追加のアーキテクチャは二次的に実装されます)。

このプロジェクトはまだ開発の初期段階にありますが、基本的な目標はすでに定義されています。

• モノリシックなセットではなく粒度の高いライブラリを提供するという哲学に従ったモジュール性と開発。
• モードでの静的リンクのサポート パイ (位置に依存しない実行可能ファイル)、PIE なし。 静的にリンクされた実行可能ファイル用の CRT (C ランタイム) および PIE ローダーを提供します。
• 標準 C ライブラリ関数のほとんどをサポートし、POSIX の追加機能や、既存のアプリケーションに必要ないくつかのシステム固有の拡張機能をサポートします。
• ベンダー固有の拡張機能には注意し、必要な場合にのみ追加してください。 サードパーティの拡張機能のサポートに関しては、Clang プロジェクトと libc++ プロジェクトのアプローチを使用することが提案されています。
• LLVM ツールキットを使用した開発では、最初からサニタイザーやファズ テストを使用するなど、ベスト プラクティスを使用します。

現役の LLVM 開発者の XNUMX 人 示されたlibc を LLVM ツールキットの一部として出荷することが合理的であることは明らかですが、通常、そのような必要が生じた場合、よく書かれ、さまざまなアーキテクチャをサポートし、動的サポートを含む必要な機能を提供する musl ライブラリが使用されます。リンクすること。 musl を LLVM に埋め込み、メイン プロジェクトと同期したフォークとして開発することが正当化される可能性があります。

あなたの意見も 表現された Musl プロジェクトの作成者は、Google の提案と LLVM ディストリビューションに Libc を含めることがなぜ非常に悪いアイデアであるかを主張しようとしました。

• 正しく、互換性があり、高品質な Libc を開発して維持することは、非常に困難な作業です。 問題はコードの量ではなく、これまでに C/C++ で書かれたアプリケーションの巨大な層や、ランタイムが使用される他の言語のアプリケーションを考慮して、正しい動作を保証することとインターフェイスの実装の難しさにあります。 Libcによる。 ニュアンスを考慮せずに正面からアプローチすると、多くの既存プログラムが Libc で動作できなくなるという事実につながるだけですが、その場合、そのようなプロジェクトは消費者にとって興味深いものではなくなります。
• 企業開発により Libc は台無しになる可能性がありますが、Libc が広く使用されるように推進すると、アプリケーションの互換性を確保するためにハッキングを追加する必要が生じます。 企業のオープンソース プロジェクトの後援による開発は、企業のニーズやソリューションに全面的に適用することになり、コミュニティの利益を損なうことになります。 たとえば、別のプログラムのバグによって引き起こされた問題を特定した場合、管理された開発では、バグ自体を修正するよりも、Libc がこのバグと互換性があることを確認する方が簡単です。 Apple はこれらの目的に BSD libc フォークを使用し、Google は Fuchsia の musl フォークを使用します。 musl 開発者の経験では、主にライセンスの問題を明確にするために弁護士から連絡を受けましたが、ブランチに無用で破壊的な変更を加える前に技術的な詳細を明確にするために連絡されることはありませんでした。
• libc 開発にはモノカルチャーが存在せず、個別の管理ではなくコンセンサス主導の標準に重点が置かれているため、アプリケーション開発者は特定の実装に縛られるのではなく標準を使用するようになります。 これが、musl の作者が自分のライブラリを LLVM に含めることに反対している理由であり、LLVM 内での libc の開発にも反対している理由です。この場合、libc の独立した性質が失われ、特定の実装が LLVM の最上級のソリューションになるからです。 LLVM とその他すべては XNUMX 番目のソリューションになります。

出所： オープンネット.ru