Un des développeurs de la société Google dans la liste de diffusion LLVM le sujet du développement d'une bibliothèque standard en C multiplateforme (Libc) dans le cadre du projet LLVM. Pour plusieurs raisons, Google n'est pas satisfait des libc actuelles (glibc, musl) et l'entreprise est en route pour développer une nouvelle implémentation, qui devrait être développée dans le cadre de LLVM.
Les travaux sur LLVM ont récemment été utilisés comme base pour la construction d'outils de compilation pour Google. L'idée principale est que si Google a déjà commencé à développer sa libc, pourquoi ne pas immédiatement développer son système au sein de LLVM, qui propose déjà sa bibliothèque standard pour C++ (Libc++), mais n'a pas de bibliothèque standard équivalente pour C (Libc).
Le développement est prévu d'être réalisé par étapes, augmentant progressivement les fonctionnalités. Les premières versions devraient être conçues comme une couche entre l'application et la Libc système, à partir de laquelle seront empruntées des fonctionnalités qui ne sont pas encore mises en œuvre. Après avoir atteint un certain niveau de fonctionnalité, la nouvelle Libc pourra être utilisée comme un remplacement complet de la Libc système. Le démarrage est prévu avec le support de l'architecture x86-64, Linux et le lien statique (le chargement dynamique, la liaison et d'autres architectures seront réalisés en second lieu).
Le projet est encore à ses débuts, mais les objectifs de base ont déjà été définis :
- Modularité et développement en conformité avec la philosophie de fournir une bibliothèque granulaire, et non un ensemble monolithique ;
- Support du lien statique en modes avec (exécutables position-indépendants) et sans PIE. Fourniture du CRT (runtime C) et du chargeur PIE pour les fichiers exécutables liés statiquement ;
- Support de la plupart des fonctions de la bibliothèque standard en C avec des ajouts POSIX et certaines extensions spécifiques au système requises dans les applications existantes ;
- Prudence vis-à-vis des extensions spécifiques aux fabricants et leur ajout uniquement si nécessaire. En ce qui concerne le soutien des extensions tierces, il est proposé d'appliquer l'approche des projets Clang et libc++;
- Utilisation des meilleures pratiques dans le développement avec les outils de LLVM, tels que l'application de sanitizer et de tests de fuzzing dès le début.
Un des développeurs actifs de LLVM , estime que l'inclusion de libc dans les outils LLVM a du sens, mais qu'en général, dans ce genre de situation, la bibliothèque musl est utilisée, qui est bien écrite, supporte différentes architectures et fournit les fonctionnalités nécessaires, y compris le support du lien dynamique. L'intégration de musl dans LLVM et son développement en tant que fork synchronisé avec le projet principal peuvent être justifiés.
Son avis a également par l'auteur du projet Musl, qui a tenté d'argumenter pourquoi la proposition de Google d'inclure libc dans la distribution de LLVM est une très mauvaise idée :
- Le développement et le maintien d'une Libc correcte, compatible et de haute qualité est une tâche très difficile. Le problème n'est pas dans le volume de code, mais dans la garantie d'un comportement correct et les difficultés d'implémentation des interfaces, en tenant compte de l'énorme ensemble d'applications jamais écrites en C/C++, ainsi que des applications dans d'autres langages dont l'exécution utilise Libc. Une approche directe sans prendre en compte les nuances ne fera que rendre de nombreuses programmes existants incompatibles avec Libc, ce qui rendra ce projet peu intéressant pour les consommateurs.
- Le développement d'entreprise peut détériorer Libc, mais mettre en avant son utilisation généralisée, ce qui nécessitera l'ajout de correctifs pour garantir la compatibilité dans les applications. Le développement sous l'égide d'un projet open source d'entreprise favorisera les besoins et solutions de l'entreprise, au détriment des intérêts de la communauté. Par exemple, lorsqu'un problème survient en raison d'un bug dans un autre de leurs programmes, dans un environnement de développement contrôlé, il est plus facile de garantir la compatibilité de Libc avec ce bug plutôt que de corriger le bug lui-même. Apple utilise pour ces fins un fork de BSD libc, tandis que Google appliquant dans Fuchsia un fork de musl. L'expérience du développeur de musl indique que la majorité des contacts ont été établis par des avocats pour des questions de licences, mais qu'ils ne se sont jamais tournés vers lui pour clarifier des détails techniques avant d'apporter des modifications inutiles et perturbant le fonctionnement dans leurs branches.
- L'absence de monoculture dans le développement de libc et l'orientation vers des normes développées sur la base d'un consensus, plutôt que vers un contrôle unique, incitent les développeurs d'applications à utiliser ces normes au lieu de s'attacher à des implementations spécifiques. C'est pourquoi l'auteur de musl s'oppose à l'inclusion de sa bibliothèque dans LLVM, tout comme à la développement de libc au sein de LLVM, car cela compromettrait le caractère indépendant de libc et ferait de l'implémentation spécifique une solution de premier plan pour LLVM, reléguant toutes les autres au second plan.
Source : opennet.ru
