Uno degli sviluppatori di Google nella mailing list LLVM il tema dello sviluppo di una libreria standard C multipiattaforma (Libc) nell'ambito del progetto LLVM. Per vari motivi, Google non è soddisfatta delle attuali libc (glibc, musl) e l'azienda è sulla strada per lo sviluppo di una nuova implementazione, che si propone di sviluppare come parte di LLVM.
Le intuizioni di LLVM sono state recentemente utilizzate come base 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 subito il proprio sistema all'interno di LLVM, che offre già la propria libreria standard per C++ (Libc++), ma non ha una libreria standard equivalente per C (Libc).
Lo sviluppo è previsto in fasi, aumentando gradualmente la funzionalità. Le prime versioni si propone di realizzarle sotto forma di interfaccia tra l'applicazione e la Libc di sistema, da cui verranno tratte funzionalità ancora non implementate. Una volta raggiunto un certo livello di funzionalità, la nuova Libc potrà essere utilizzata come sostituzione completa della Libc di sistema. Si prevede di iniziare con il supporto per l'architettura x86-64, Linux e il collegamento statico (il caricamento dinamico, il linking e ulteriori architetture saranno implementati in un secondo momento).
Il progetto è ancora nelle fasi iniziali di sviluppo, ma sono già stati definiti obiettivi di base:
- Modularità e sviluppo in conformità con la filosofia di fornire una libreria granulare, piuttosto che un insieme monolitico;
- Supporto per il collegamento statico nelle modalità con (eseguibili indipendenti dalla posizione) e senza PIE. Fornitura di CRT (C runtime) e caricatore PIE per file eseguibili staticamente collegati;
- Supporto per la maggior parte delle funzioni della libreria standard C con aggiunte POSIX e alcune estensioni specifiche per sistemi richieste nelle applicazioni esistenti;
- Attenzione particolare agli ampliamenti specifici per i produttori e la loro aggiunta solo se necessario. Per quanto riguarda il supporto delle estensioni di terze parti, si propone di adottare l'approccio dei progetti Clang e libc++;
- Uso delle pratiche esemplari nello sviluppo utilizzando gli strumenti di LLVM, come l'applicazione di sanitizer e test di fuzzing fin dall'inizio.
Uno degli sviluppatori attivi di LLVM , che la fornitura della libc come parte degli strumenti LLVM non sia priva di senso, ma di solito, in tale necessità, si utilizza la libreria musl, che è scritta con qualità, supporta diverse architetture e fornisce la funzionalità necessaria, incluso il supporto per il linking dinamico. L'integrazione di musl in LLVM e il suo sviluppo come fork sincronizzato con il progetto principale può essere giustificata.
La propria opinione ha anche l'autore del progetto Musl, che ha cercato di argomentare perché la proposta di Google e l'inclusione della Libc nella fornitura di LLVM siano idee molto sbagliate:
- Lo sviluppo e la manutenzione di una Libc corretta, compatibile e di alta qualità è un compito molto difficile. Il problema non risiede nel volume del codice, ma nell'assicurare un comportamento corretto e nelle difficoltà di implementazione delle interfacce, considerando l'enorme numero di applicazioni scritte in C/C++, così come le applicazioni in altri linguaggi il cui runtime utilizza la Libc. Un approccio diretto senza considerare le sfumature porterà solo a rendere molte delle applicazioni esistenti incompatibili con la Libc, ma in tal caso un progetto del genere non sarà interessante per i consumatori.
- Lo sviluppo aziendale può rovinare la Libc, ma sarà spinto per un uso diffuso, il che porterà alla necessità di aggiungere hack per garantire la compatibilità nelle applicazioni. Lo sviluppo sotto l'egida di un progetto open source aziendale tirerà la coperta dalla parte delle esigenze e delle soluzioni dell'azienda, a scapito degli interessi della comunità. Ad esempio, nel caso venga individuato un problema causato da un errore in un'altra propria applicazione, in uno sviluppo controllato è più semplice garantire la compatibilità della Libc con questo errore piuttosto che correggere l'errore stesso. Apple utilizza a tal fine un fork della BSD libc, mentre Google applica in Fuchsia un fork di musl. L'esperienza del sviluppatore di musl indica che le persone che lo hanno contattato erano principalmente avvocati per chiarire questioni di licenza, ma mai per chiedere dettagli tecnici prima di apportare cambiamenti inutili e che interferiscono con il funzionamento nelle loro ramificazioni.
- L'assenza di monocoltura nello sviluppo della libc e l'orientamento verso standard sviluppati su base di consenso, invece di una gestione autocratica, motivano gli sviluppatori di applicazioni a utilizzare standard e a non legarsi a implementazioni specifiche. È per questo che l'autore di musl si oppone all'inclusione della sua libreria nel framework LLVM, così come allo sviluppo della libc all'interno di LLVM, poiché in questo caso si perderebbe il carattere indipendente della libc e una determinata implementazione diventerebbe una soluzione di primo livello per LLVM, mentre tutte le altre sarebbero di secondo livello.
Fonte: opennet.ru
