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 開發人員之一 指出很明顯，將libc 作為LLVM 工具包的一部分提供是有意義的，但通常，當出現這種需要時，他們會使用musl 庫，該庫編寫得很好，支援各種體系結構，並提供必要的功能，包括對動態的支援連結。 將 musl 嵌入到 LLVM 中並將其開發為與主專案同步的分支可能是合理的。

你的意見也 表達 Musl 專案的作者試圖論證為什麼 Google 的提議以及將 Libc 納入 LLVM 發行版是非常糟糕的想法：

• 開發和維護一個正確的、相容的、高品質的Libc是一項非常艱鉅的任務。 問題不在於程式碼量，而是確保正確的行為和實現介面的困難，考慮到用 C/C++ 編寫的應用程式的巨大層，以及使用其運行時的其他語言的應用程式由 Libc 提供。 不考慮細微差別的正面做法只會導致許多現有程式無法與 Libc 配合使用，但這樣的專案將不會引起消費者的興趣。
• 企業開發可能會毀掉 Libc，但會推動它廣泛使用，從而導致需要添加 hack 來確保應用程式的兼容性。 在企業開源專案的支持下進行開發將會掩蓋公司的需求和解決方案，從而損害社群的利益。 例如，如果您發現一個問題是由另一個程式中的錯誤引起的，那麼在受控開發中，確保 Libc 與此錯誤相容比修復錯誤本身更容易。 Apple 使用 BSD libc 分支來實現這些目的，而 Google 在 Fuchsia 中使用 musl 分支。 musl 開發人員的經驗是，主要由律師聯繫他以澄清許可問題，但在對其分支機構進行無用且具有破壞性的更改之前從未聯繫過他以澄清技術細節。
• libc 開發中不存在單一文化，並且注重共識驅動的標準而不是個人控制，這促使應用程式開發人員使用標準而不是受特定實現的束縛。 這就是為什麼 musl 的作者反對將他的庫包含在 LLVM 中，也反對在 LLVM 中開發 libc，因為在這種情況下，libc 的獨立性就會丟失，某種實現會成為一流的解決方案。LLVM和所有其他解決方案都成為二流解決方案。

來源： opennet.ru