Een van de ontwikkelaars van Google op de LLVM-mailinglijst over de ontwikkeling van een multi-platform standaard C-bibliotheek (Libc) als onderdeel van het LLVM-project. Om een aantal redenen is Google niet tevreden met de huidige libc (glibc, musl) en is het bedrijf op weg om een nieuwe implementatie te ontwikkelen, die naar verwachting zal worden ontwikkeld als onderdeel van LLVM.
LLVM-ontwikkelingen zijn onlangs gebruikt als basis voor het bouwen van de assemblagetools van Google. Het belangrijkste idee is dat als Google al is begonnen met het ontwikkelen van zijn libc, waarom dan niet onmiddellijk zijn systeem zou ontwikkelen als onderdeel van LLVM, dat al zijn eigen standaardbibliotheek voor C++ (Libc++) biedt, maar geen vergelijkbare standaardbibliotheek voor C heeft. (libc).
Het is de bedoeling dat de ontwikkeling in fasen wordt uitgevoerd, waarbij de functionaliteit geleidelijk toeneemt. Er wordt voorgesteld om de eerste opties te ontwerpen als een laag tussen de applicatie en het systeem Libc, waarvan nog niet geïmplementeerde functies zullen worden overgenomen. Na het bereiken van een bepaald functionaliteitsniveau kan de nieuwe Libc worden gebruikt als volledige vervanging van het systeem Libc. We zijn van plan om te beginnen met ondersteuning voor x86-64-architectuur, Linux en statische koppelingen (dynamisch laden, koppelen en aanvullende architecturen zullen secundair worden geïmplementeerd).
Het project bevindt zich nog in de beginfase van ontwikkeling, maar de basisdoelen zijn al gedefinieerd:
- Modulariteit en ontwikkeling in overeenstemming met de filosofie van het leveren van een granulaire bibliotheek in plaats van een monolithische set;
- Ondersteuning voor statische koppeling in modi (Positie-onafhankelijke uitvoerbare bestanden) en zonder PIE. Het leveren van CRT (C runtime) en PIE-lader voor statisch gekoppelde uitvoerbare bestanden;
- Ondersteuning voor de meeste standaard C-bibliotheekfuncties, met POSIX-toevoegingen en enkele systeemspecifieke uitbreidingen die vereist zijn voor bestaande applicaties;
- Wees voorzichtig met leverancierspecifieke extensies en voeg deze alleen toe als dat nodig is. Wat betreft ondersteuning voor extensies van derden wordt voorgesteld om de aanpak van de Clang- en libc++-projecten te gebruiken;
- Het gebruik van best practices bij de ontwikkeling met behulp van de LLVM-toolkit, zoals het gebruik van ontsmettingsmiddel en fuzz-tests vanaf het allereerste begin.
Een van de actieve LLVM-ontwikkelaars Het is duidelijk dat het zinvol is om libc te leveren als onderdeel van de LLVM-toolkit, maar meestal gebruiken ze, wanneer een dergelijke behoefte zich voordoet, de musl-bibliotheek, die goed geschreven is, verschillende architecturen ondersteunt en de noodzakelijke functionaliteit biedt, inclusief ondersteuning voor dynamische koppelen. Het kan gerechtvaardigd zijn om musl in LLVM in te bedden en het te ontwikkelen als een vork die gesynchroniseerd is met het hoofdproject.
Jouw mening ook De auteur van het Musl-project, die probeerde te beargumenteren waarom het voorstel van Google en de opname van Libc in de LLVM-distributie zeer slechte ideeën zijn:
- Het ontwikkelen en onderhouden van een correcte, compatibele en hoogwaardige Libc is een zeer moeilijke taak. Het probleem zit niet in de hoeveelheid code, maar in het garanderen van correct gedrag en problemen bij het implementeren van interfaces, rekening houdend met de enorme laag applicaties die ooit in C/C++ zijn geschreven, evenals applicaties in andere talen waarvan de runtime wordt gebruikt door Libc. Een frontale aanpak zonder rekening te houden met de nuances zal er alleen maar toe leiden dat veel bestaande programma's niet met Libc kunnen werken, maar dan zal zo'n project niet interessant zijn voor consumenten.
- Bedrijfsontwikkeling kan Libc ruïneren, maar het op grote schaal gebruiken, wat resulteert in de noodzaak om hacks toe te voegen om compatibiliteit in applicaties te garanderen. Ontwikkeling onder auspiciën van een open source-project van een bedrijf zal de aandacht vestigen op de behoeften en oplossingen van het bedrijf, ten koste van de belangen van de gemeenschap. Als u bijvoorbeeld een probleem identificeert dat wordt veroorzaakt door een bug in een ander programma, is het bij gecontroleerde ontwikkeling gemakkelijker om ervoor te zorgen dat Libc compatibel is met deze bug dan om de bug zelf te repareren. Apple gebruikt voor deze doeleinden de BSD libc-vork, en Google gebruikt de musl-vork in Fuchsia. De ervaring van de musl-ontwikkelaar is dat hij voornamelijk door advocaten werd gecontacteerd om licentiekwesties op te helderen, maar nooit werd gecontacteerd om technische details te verduidelijken voordat hij nutteloze en ontwrichtende wijzigingen in zijn vestigingen aanbracht.
- De afwezigheid van een monocultuur in libc-ontwikkeling en een focus op op consensus gebaseerde standaarden in plaats van individuele controle, wat applicatie-ontwikkelaars motiveert om standaarden te gebruiken in plaats van gebonden te zijn aan specifieke implementaties. Daarom is de auteur van musl tegen het opnemen van zijn bibliotheek in LLVM, evenals tegen de ontwikkeling van libc binnen LLVM, omdat in dit geval het onafhankelijke karakter van libc verloren gaat en een bepaalde implementatie een eersteklas oplossing wordt voor LLVM en alle andere worden een tweederangsoplossing.
Bron: opennet.ru