L'un des développeurs de Google sur la liste de diffusion LLVM à propos du développement d'une bibliothèque C standard multiplateforme (Libc) dans le cadre du projet LLVM. Pour un certain nombre de raisons, Google n'est pas satisfait de la libc actuelle (glibc, musl) et la société est sur le point de développer une nouvelle implémentation, qu'il est proposé de développer dans le cadre de LLVM.
Les développements LLVM ont récemment été utilisés comme base pour créer les outils d'assemblage de Google. L'idée principale est que si Google a déjà commencé à développer sa libc, pourquoi ne pas développer immédiatement son système dans le cadre de LLVM, qui propose déjà sa propre bibliothèque standard pour C++ (Libc++), mais ne dispose pas d'une bibliothèque standard similaire pour C. (libc).
Le développement devrait être effectué par étapes, augmentant progressivement les fonctionnalités. Les premières options sont proposées pour être conçues comme une couche entre l'application et le système Libc, à partir de laquelle seront empruntées des fonctionnalités qui n'ont pas encore été implémentées. Après avoir atteint un certain niveau de fonctionnalité, la nouvelle Libc peut être utilisée en remplacement complet de la Libc système. Nous prévoyons de commencer par la prise en charge de l'architecture x86-64, de Linux et des liaisons statiques (le chargement dynamique, les liaisons et les architectures supplémentaires seront implémentées en second lieu).
Le projet en est encore au stade initial de développement, mais les objectifs fondamentaux ont déjà été définis :
- Modularité et développement conformément à la philosophie de fournir une bibliothèque granulaire plutôt qu'un ensemble monolithique ;
- Prise en charge des liaisons statiques dans les modes (Exécutables indépendants de la position) et sans PIE. Fournir un chargeur CRT (C runtime) et PIE pour les exécutables liés statiquement ;
- Prise en charge de la plupart des fonctions standard de la bibliothèque C, avec des ajouts POSIX et certaines extensions spécifiques au système requises par les applications existantes ;
- Soyez prudent avec les extensions spécifiques au fournisseur et ajoutez-les uniquement lorsque cela est nécessaire. Concernant le support des extensions tierces, il est proposé d'utiliser l'approche des projets Clang et libc++ ;
- Utiliser les meilleures pratiques de développement à l'aide de la boîte à outils LLVM, telles que l'utilisation de désinfectants et de tests de fuzz dès le début.
L'un des développeurs LLVM actifs Il est clair qu'il est logique de fournir la libc dans le cadre de la boîte à outils LLVM, mais généralement, lorsqu'un tel besoin se fait sentir, ils utilisent la bibliothèque musl, qui est bien écrite, prend en charge diverses architectures et fournit les fonctionnalités nécessaires, y compris la prise en charge des dynamiques. mise en relation. Il peut être justifié d'intégrer musl dans LLVM et de le développer comme un fork synchronisé avec le projet principal.
Votre avis également L'auteur du projet Musl, qui a tenté d'expliquer pourquoi la proposition de Google et l'inclusion de Libc dans la distribution LLVM sont de très mauvaises idées :
- Développer et maintenir une Libc correcte, compatible et de haute qualité est une tâche très difficile. Le problème ne réside pas dans la quantité de code, mais dans la garantie d'un comportement correct et des difficultés d'implémentation des interfaces, compte tenu de l'énorme couche d'applications jamais écrites en C/C++, ainsi que des applications dans d'autres langages dont le runtime est utilisé. par Libc. Une approche frontale sans prendre en compte les nuances ne fera que conduire au fait que de nombreux programmes existants ne pourront pas fonctionner avec Libc, mais un tel projet n'intéressera alors pas les consommateurs.
- Le développement d'entreprise peut ruiner Libc, mais il faut le pousser à une utilisation généralisée, ce qui entraîne la nécessité d'ajouter des hacks pour garantir la compatibilité des applications. Le développement sous les auspices d'un projet open source d'entreprise tirera le voile vers les besoins et les solutions de l'entreprise, au détriment des intérêts de la communauté. Par exemple, si vous identifiez un problème causé par un bug dans un autre programme, en développement contrôlé, il est plus facile de s'assurer que Libc est compatible avec ce bug que de corriger le bug lui-même. Apple utilise le fork libc BSD à ces fins, et Google utilise le fork musl dans Fuchsia. L'expérience du développeur musl est qu'il a été contacté principalement par des avocats pour clarifier des questions de licence, mais n'a jamais été contacté pour clarifier des détails techniques avant d'apporter des modifications inutiles et perturbatrices à ses branches.
- L'absence de monoculture dans le développement de la libc et l'accent mis sur des normes consensuelles plutôt que sur un contrôle individuel, ce qui motive les développeurs d'applications à utiliser des normes plutôt que d'être liés à des implémentations spécifiques. C'est pourquoi l'auteur de musl est contre l'inclusion de sa bibliothèque dans LLVM, ainsi que contre le développement de la libc au sein de LLVM, puisque dans ce cas la nature indépendante de la libc est perdue et une certaine implémentation devient une solution de premier ordre pour LLVM et tous les autres deviennent une solution de seconde classe.
Source: opennet.ru