Un dels desenvolupadors de Google a la llista de correu LLVM sobre el desenvolupament d'una biblioteca C estàndard multiplataforma (Libc) com a part del projecte LLVM. Per diverses raons, Google no està satisfet amb la libc actual (glibc, musl) i l'empresa està en camí de desenvolupar una nova implementació, que es proposa desenvolupar com a part de LLVM.
Recentment, els desenvolupaments LLVM s'han utilitzat com a base per construir les eines de muntatge de Google. La idea principal és que si Google ja ha començat a desenvolupar la seva libc, per què no desenvolupar immediatament el seu sistema com a part de LLVM, que ja ofereix la seva pròpia biblioteca estàndard per a C++ (Libc++), però no té una biblioteca estàndard similar per a C. (libc).
El desenvolupament està previst que es dugui a terme per etapes, augmentant gradualment la funcionalitat. Es proposa que les primeres opcions es dissenyin com una capa entre l'aplicació i el sistema Libc, de la qual es prendran prestades característiques que encara no s'han implementat. Després d'arribar a un cert nivell de funcionalitat, el nou Libc es pot utilitzar com a substitut complet del sistema Libc. Tenim previst començar amb suport per a l'arquitectura x86-64, Linux i enllaços estàtics (la càrrega dinàmica, l'enllaç i les arquitectures addicionals s'implementaran secundàriament).
El projecte encara es troba en la fase inicial de desenvolupament, però ja s'han definit els objectius bàsics:
- Modularitat i desenvolupament d'acord amb la filosofia de lliurar una biblioteca granular en lloc d'un conjunt monolític;
- Suport per a l'enllaç estàtic en els modes amb (Executables independents de la posició) i sense PIE. Proporcionar CRT (temps d'execució C) i carregador PIE per a executables enllaçats estàticament;
- Suport per a la majoria de les funcions estàndard de la biblioteca C, amb addicions POSIX i algunes extensions específiques del sistema requerides per les aplicacions existents;
- Aneu amb compte amb les extensions específiques del proveïdor i només afegiu-les quan sigui necessari. Pel que fa al suport per a extensions de tercers, es proposa utilitzar l'enfocament dels projectes Clang i libc++;
- Ús de les millors pràctiques en desenvolupament mitjançant el conjunt d'eines LLVM, com ara l'ús de desinfectants i proves de fuzz des del principi.
Un dels desenvolupadors LLVM actius Està clar que té sentit enviar libc com a part del conjunt d'eines LLVM, però normalment, quan sorgeix aquesta necessitat, utilitzen la biblioteca musl, que està ben escrita, admet diverses arquitectures i proporciona la funcionalitat necessària, inclosa el suport per a dinàmiques. enllaçant. Es pot justificar incrustar musl a LLVM i desenvolupar-lo com una bifurcació sincronitzada amb el projecte principal.
La teva opinió també L'autor del projecte Musl, que va intentar argumentar per què la proposta de Google i la inclusió de Libc a la distribució LLVM són molt males idees:
- Desenvolupar i mantenir un Libc correcte, compatible i d'alta qualitat és una tasca molt difícil. El problema no està en la quantitat de codi, sinó en garantir un comportament correcte i les dificultats en la implementació d'interfícies, tenint en compte l'enorme capa d'aplicacions mai escrites en C/C++, així com les aplicacions en altres llenguatges, el temps d'execució de les quals s'utilitza. per Libc. Un enfocament frontal sense tenir en compte els matisos només portarà al fet que molts programes existents no podran funcionar amb Libc, però llavors aquest projecte no interessarà als consumidors.
- El desenvolupament corporatiu pot arruïnar Libc, però empènyer-lo per a un ús generalitzat, la qual cosa comporta la necessitat d'afegir hacks per garantir la compatibilitat a les aplicacions. El desenvolupament sota els auspicis d'un projecte corporatiu de codi obert tirarà de la manta cap a les necessitats i solucions de l'empresa, en detriment dels interessos de la comunitat. Per exemple, si identifiqueu un problema causat per un error en un altre programa, en el desenvolupament controlat és més fàcil assegurar-vos que Libc és compatible amb aquest error que corregir l'error en si. Apple utilitza la forquilla BSD libc per a aquests propòsits, i Google utilitza la forquilla musl a Fuchsia. L'experiència del desenvolupador de musl és que va ser contactat principalment per advocats per aclarir problemes de llicència, però mai no es va contactar per aclarir detalls tècnics abans de fer canvis inútils i perjudicials a les seves oficines.
- L'absència d'un monocultiu en el desenvolupament de libc i un enfocament en estàndards basats en el consens en lloc del control exclusiu, que motiva els desenvolupadors d'aplicacions a utilitzar estàndards en lloc d'estar lligats a implementacions específiques. És per això que l'autor de musl està en contra de la inclusió de la seva biblioteca a LLVM, així com en contra del desenvolupament de la libc dins de LLVM, ja que en aquest cas es perd la naturalesa independent de la libc i una certa implementació esdevé una solució de primer nivell per LLVM i tots els altres es converteixen en una solució de segona classe.
Font: opennet.ru