Uno dei sviluppatori di Google sulla mailing list di LLVM il tema dello sviluppo di una libreria standard C multipiattaforma (Libc) nel quadro del progetto LLVM. Per vari motivi, Google non è soddisfatta delle attuali libc (glibc, musl) e l'azienda sta lavorando a una nuova implementazione, che si propone di sviluppare come parte di LLVM.
Negli ultimi tempi, le basi di LLVM sono state utilizzate come fondamenta per costruire gli strumenti di compilazione di Google. L'idea principale è che se Google ha già iniziato a sviluppare la propria libc, perché non sviluppare anche il proprio sistema all'interno di LLVM, che già offre la sua libreria standard per C++ (Libc++) ma non ha una corrispondente libreria standard per C (Libc).
La pianificazione dello sviluppo avverrà in fasi, aumentando gradualmente le funzionalità. Le prime versioni saranno proposte come uno strato intermedio tra l’applicazione e la Libc di sistema, da cui saranno attinte funzionalità ancora non implementate. Dopo aver raggiunto un certo livello di funzionalità, la nuova Libc potrà essere utilizzata come sostituzione completa della Libc di sistema. Si inizierà con il supporto per l'architettura x86-64, Linux e il collegamento statico (il caricamento dinamico, la compattazione e architetture aggiuntive saranno implementati in un secondo momento).
Il progetto è ancora in fase iniziale, ma sono già definiti obiettivi di base:
- Modularità e sviluppo in conformità con la filosofia della fornitura di una libreria granulare, piuttosto che di un insieme monolitico;
- Supporto per il collegamento statico in modalità con (executables indipendenti dalla posizione) e senza PIE. Fornitura di CRT (C runtime) e caricatore PIE per file eseguibili collegati staticamente;
- Supporto della maggior parte delle funzioni della libreria standard C con integrazioni POSIX e alcune estensioni specifiche per i sistemi richieste nelle applicazioni esistenti;
- Un atteggiamento cauto nei confronti delle estensioni specifiche dei produttori e la loro integrazione solo se necessario. Per quanto riguarda il supporto delle estensioni di terze parti, si propone di adottare l'approccio dei progetti Clang e libc++;
- Utilizzo di pratiche esemplari nello sviluppo utilizzando gli strumenti LLVM, come l'applicazione di sanitizer e il fuzzing fin dall'inizio.
Uno degli sviluppatori attivi di LLVM , quindi la fornitura di libc all'interno degli strumenti LLVM non è priva di senso, ma normalmente in situazioni simili viene utilizzata la libreria musl, che è ben scritta, supporta diverse architetture e offre la funzionalità necessaria, inclusa la supporto per il linking dinamico. Può essere giustificata l'integrazione di musl in LLVM e lo sviluppo come un fork sincronizzato con il progetto principale.
La sua opinione è stata espressa anche l'autore del progetto Musl, che ha cercato di argomentare perché la proposta di Google e l'inclusione di Libc nella fornitura di LLVM siano idee molto cattive:
- Lo sviluppo e la manutenzione di una Libc corretta, compatibile e di alta qualità è un compito molto difficile. Il problema non riguarda la quantità di codice, ma va garantito un comportamento corretto e affrontare le difficoltà nella realizzazione delle interfacce, considerando la vasta gamma di applicazioni scritte in C/C++ e in altri linguaggi, il cui runtime utilizza Libc. Un approccio diretto senza considerare le sfumature porterà a far sì che molti programmi esistenti non siano in grado di funzionare con Libc, rendendo così il progetto poco interessante per i consumatori.
- Lo sviluppo aziendale può compromettere Libc, spingendo per un ampio utilizzo, il che porta alla necessità di aggiungere hack per garantire la compatibilità nelle applicazioni. Lo sviluppo sotto l'egida di un progetto open source aziendale tende a favorire le esigenze e le soluzioni della compagnia, a discapito degli interessi della comunità. Ad esempio, se emergesse un problema causato da un errore in un altro programma di loro proprietà, nella sviluppo controllato sarebbe più semplice garantire la compatibilità di Libc con questo errore, che non correggere l'errore stesso. Apple utilizza a tal fine un fork di BSD libc, mentre Google usa in Fuchsia un fork di musl. L'esperienza di un sviluppatore di musl indica che i contatti sono avvenuti principalmente con avvocati per chiarimenti su questioni di licenza, ma mai per chiarire dettagli tecnici prima di apportare cambiamenti inutili e perturbanti nelle loro diramazioni.
- L'assenza di monocultura nello sviluppo di libc e l'orientamento verso standard sviluppati sulla base del consenso anziché di una gestione centralizzata motivano gli sviluppatori di applicazioni a utilizzare gli standard, invece di legarsi a implementazioni specifiche. È per questo che l'autore di musl si oppone all'inclusione della sua libreria in LLVM, così come allo sviluppo di libc nell'ambito di LLVM, poiché in questo caso si perderebbe il carattere indipendente di libc e una determinata implementazione diventerebbe una soluzione di prima classe per LLVM, mentre tutte le altre rimarrebbero di seconda classe.
Fonte: opennet.ru
