Les développeurs Google veulent développer leur propre libc pour LLVM

LLVM_Logo

L'un des développeurs Google a présenté sur la liste de diffusion LLVM le sujet du développement une bibliothèque C standard multiplateforme (Libc) dans le cadre du projet LLVM.

Pour plusieurs raisons, Google n'est pas satisfait de la libc actuelle (glibc, musl) et l'entreprise est sur la bonne voie pour développer une nouvelle implémentation, qu'il entend développer dans le cadre de LLVM. Les développements de LLVM ont récemment été utilisés comme base pour créer des outils Google.

Le développement est prévu pour être progressif, augmentant progressivement la fonctionnalité. Il est proposé que les premières options prennent la forme d'une couche intermédiaire entre l'application et le système libc, à partir de laquelle les fonctionnalités non réalisées seront empruntées.

Après avoir atteint un certain niveau de fonctionnalité, la nouvelle Libc peut être utilisée en remplacement complet du système Libc.

Il est prévu de commencer par la prise en charge de l'architecture x86-64, de Linux et de la liaison statique (le chargement dynamique, l'empaquetage et les architectures supplémentaires seront implémentés en second lieu).

Le projet en est encore au stade initial de développement, mais les objectifs de base ont déjà été définis:

  • Modularité et développement selon la philosophie de fourniture d'une bibliothèque granulaire, plutôt qu’un ensemble monolithique.
  • Prise en charge des liaisons statiques dans les modes PIE (exécutables indépendants de la position) et sans PIE. Fournissez CRT (runtime C) et le chargeur PIE pour les fichiers exécutables liés statiquement.
  • Prend en charge la plupart des fonctions de la bibliothèque C standard avec les plug-ins POSIX et certaines extensions spécifiques au système qui sont demandées dans les applications existantes.
  • Attitude prudente envers les extensions spécifiques du fournisseur et ne les ajoutant que lorsque cela est nécessaire. Pour la prise en charge des extensions tierces, il est proposé d'utiliser l'approche de projet Clang et libc ++.
  • Utilisation des meilleures pratiques de développement à l'aide des outils LLVM, comme l'application de désinfectants et l'élimination des tests dès le début.

L'un des développeurs LLVM actifs a indiqué que livraison de la libc dans le cadre de la boîte à outils LLVM ce n'est pas sans signification, mais généralement avec un tel besoin ils utilisent la bibliothèque musulmane, Il est bien écrit, prend en charge plusieurs architectures et fournit les fonctionnalités nécessaires, y compris la liaison dynamique.

L'incorporation de Musl dans LLVM et son développement en tant que fork synchronisé avec le projet principal peuvent être justifiés.

Son opinion a également été exprimée par l'auteur du projet Musl, qui a tenté d'expliquer pourquoi la proposition de Google et l'inclusion de Libc dans la livraison de LLVM sont de très mauvaises idées:

Développer et maintenir la libc correcte, compatible et de haute qualité est une tâche très difficile. Le problème n'est pas dans la quantité de code, mais dans le comportement correct.

Et les difficultés d'implémentation de l'interface, compte tenu de l'énorme référentiel d'applications écrites en C / C ++, ainsi que des applications dans d'autres langages dont le runtime est utilisé par Libc.

L'approche du front sans prendre en compte les nuances ne fera que conduire au fait que de nombreux programmes existants ne pourront pas travailler avec Libc, mais un tel projet n'intéressera pas les consommateurs.

Le développement d'entreprise peut ruiner Libc, mais conduisent à une utilisation généralisée, ce qui entraînera la nécessité d'ajouter des hacks pour assurer la compatibilité des applications.

Le développement sous les auspices d'un projet d'entreprise ouvert favorisera la couverture des besoins et des décisions de l'entreprise, au détriment des intérêts de la communauté.

Par exemple, dans le cas de l'identification d'un problème causé par une erreur dans un autre programme de votre choix, dans le développement sous contrôle, il est plus facile de garantir la compatibilité de Libc avec cette erreur que de corriger l'erreur elle-même.

Apple utilise le fork de la libc BSD à ces fins et Google utilise le fork Fuchsia. L'expérience de développeur de Musl suggère que les avocats l'ont contacté principalement pour clarifier les problèmes de licence.

source: http://lists.llvm.org


Le contenu de l'article adhère à nos principes de éthique éditoriale. Pour signaler une erreur, cliquez sur c'est par ici !.

Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.