Een van de Google-ontwikkelaars presenteerde op de LLVM-mailinglijst het onderwerp ontwikkelen een platformonafhankelijke standaard C-bibliotheek (Libc) in het kader van het LLVM-project.
Om verschillende redenen Google is niet tevreden met de huidige libc (glibc, musl) en het bedrijf ligt op schema om een nieuwe implementatie te ontwikkelen, die hij wil ontwikkelen als onderdeel van LLVM. LLVM-ontwikkelingen zijn onlangs gebruikt als basis voor het bouwen van Google-tools.
De ontwikkeling is gepland om geleidelijk te verlopen, waarbij de functionaliteit geleidelijk toeneemt. Voorgesteld wordt dat de eerste opties de vorm aannemen van een tussenlaag tussen de applicatie en het libc-systeem, waaruit de niet-gerealiseerde features zullen worden overgenomen.
Nadat een bepaald niveau van functionaliteit is bereikt, kan de nieuwe Libc worden gebruikt als een complete vervanging voor het Libc-systeem.
Het is de bedoeling om te beginnen met ondersteuning voor de x86-64-architectuur, Linux en statische binding (dynamisch laden, verpakken en aanvullende architecturen worden als tweede geïmplementeerd).
Het project bevindt zich nog in de beginfase van ontwikkeling, maar de basisdoelstellingen zijn al gedefinieerd:
- Modulariteit en ontwikkeling in overeenstemming met de filosofie van het leveren van een granulaire bibliotheek, in plaats van een monolithisch ensemble.
- Ondersteuning voor statische verbindingen in PIE-modi (positie-onafhankelijke executables) en zonder PIE. Biedt CRT (C runtime) en PIE-lader voor statisch gekoppelde uitvoerbare bestanden.
- Ondersteunt de meeste C-bibliotheekfuncties standaard met POSIX-plug-ins en enkele systeemspecifieke extensies die worden aangevraagd in bestaande applicaties.
- Zorgvuldige houding ten opzichte van specifieke extensies van de provider en voeg ze alleen toe als dat nodig is. Voor ondersteuning van extensies van derden wordt voorgesteld om de projectaanpak Clang en libc ++ te gebruiken.
- Best practices in ontwikkeling gebruiken met behulp van LLVM-tools, zoals het aanbrengen van ontsmettingsmiddelen en het verwijderen van bewijsmateriaal vanaf het begin.
Een van de actieve LLVM-ontwikkelaars gaf dat aan libc levering als onderdeel van LLVM toolkit het is niet zonder betekenis, maar over het algemeen gebruiken ze met zo'n behoefte de musl-bibliotheek, Het is goed geschreven, ondersteunt meerdere architecturen en biedt de nodige functionaliteit, inclusief dynamische koppeling.
De opname van Musl in LLVM en de ontwikkeling ervan als een gesynchroniseerde vork met het hoofdproject kan worden gerechtvaardigd.
Zijn mening werd ook uitgedrukt door de auteur van het Musl-project, die probeerde te beargumenteren waarom het voorstel van Google en de opname van Libc in de LLVM-levering zeer slechte ideeën zijn:
Het ontwikkelen en onderhouden van de juiste, compatibele en hoogwaardige libc is een zeer moeilijke taak. Het probleem zit hem niet in de hoeveelheid code, maar in het leveren van het juiste gedrag.
En de moeilijkheden met interface-implementatie, gezien de enorme opslagplaats van applicaties geschreven in C / C ++, evenals applicaties in andere talen waarvan de runtime wordt gebruikt door Libc.
De benadering van het voorhoofd zonder rekening te houden met de nuances zal er alleen maar toe leiden dat veel bestaande programma's niet met Libc kunnen werken, maar een dergelijk project zal niet interessant zijn voor consumenten.
Bedrijfsontwikkeling kan Libc ruïneren, maar zorgen voor wijdverbreid gebruik, wat zal resulteren in de noodzaak om hacks toe te voegen om compatibiliteit in applicaties te garanderen.
Ontwikkeling onder auspiciën van een open bedrijfsproject zal zorgen voor dekking in de richting van de behoeften en beslissingen van het bedrijf, ten koste van de belangen van de gemeenschap.
Als u bijvoorbeeld een probleem identificeert dat wordt veroorzaakt door een fout in een ander programma van uzelf, in de ontwikkeling die onder controle is, is het gemakkelijker om de compatibiliteit van Libc met deze fout te garanderen dan om de fout zelf te corrigeren.
Apple gebruikt voor deze doeleinden de BSD libc-vork en Google gebruikt de Fuchsia-vork. Musl's ervaring met ontwikkelaars suggereert dat de advocaten voornamelijk contact met hem hebben opgenomen om de licentiekwesties op te helderen.
bron: http://lists.llvm.org