Gli sviluppatori di Google hanno suggerito di sviluppare la propria libc per LLVM

Uno degli sviluppatori di Google sollevato sulla mailing list LLVM sullo sviluppo di una libreria C standard multipiattaforma (Libc) come parte del progetto LLVM. Per una serie di motivi Google non è soddisfatta dell'attuale libc (glibc, musl) e l'azienda è sulla buona strada per sviluppare una nuova implementazione, che si propone di essere sviluppata come parte di LLVM.

Gli sviluppi LLVM sono stati recentemente utilizzati come base per la creazione degli strumenti di assemblaggio di Google. L'idea principale è che se Google ha già iniziato a sviluppare la sua libc, perché non sviluppare immediatamente il suo sistema come parte di LLVM, che offre già la propria libreria standard per C++ (Libc++), ma non ha una libreria standard simile per C (libc).

Si prevede che lo sviluppo verrà effettuato in più fasi, aumentando gradualmente la funzionalità. Si propone che le prime opzioni siano progettate come uno strato tra l'applicazione e il sistema Libc, da cui verranno prese in prestito le funzionalità non ancora implementate. Dopo aver raggiunto un certo livello di funzionalità, la nuova Libc può essere utilizzata come sostituto completo del sistema Libc. Prevediamo di iniziare con il supporto per l'architettura x86-64, Linux e il collegamento statico (il caricamento dinamico, il collegamento e le architetture aggiuntive verranno implementati successivamente).

Il progetto è ancora nella fase iniziale di sviluppo, ma gli obiettivi fondamentali sono già stati definiti:

• Modularità e sviluppo secondo la filosofia di fornire una libreria granulare piuttosto che un insieme monolitico;
• Supporto per il collegamento statico nelle modalità PIE (Eseguibili indipendenti dalla posizione) e senza PIE. Fornire CRT (runtime C) e caricatore PIE per eseguibili collegati staticamente;
• Supporto per la maggior parte delle funzioni della libreria C standard, con aggiunte POSIX e alcune estensioni specifiche del sistema richieste dalle applicazioni esistenti;
• Fai attenzione alle estensioni specifiche del fornitore e aggiungile solo quando necessario. Per quanto riguarda il supporto alle estensioni di terze parti, si propone di utilizzare l'approccio dei progetti Clang e libc++;
• Utilizzo delle migliori pratiche di sviluppo utilizzando il toolkit LLVM, come l'utilizzo di disinfettanti e test fuzz fin dall'inizio.

Uno degli sviluppatori LLVM attivi hoÈ chiaro che ha senso fornire libc come parte del toolkit LLVM, ma di solito, quando si presenta una tale necessità, usano la libreria musl, che è ben scritta, supporta varie architetture e fornisce le funzionalità necessarie, incluso il supporto per dinamiche collegamento. Potrebbe valere la pena incorporare musl in LLVM e svilupparlo come un fork sincronizzato con il progetto principale.

Anche la tua opinione egli ha espresso L'autore del progetto Musl, che ha cercato di argomentare perché la proposta di Google e l'inclusione di Libc nella distribuzione LLVM sono pessime idee:

• Sviluppare e mantenere una Libc corretta, compatibile e di alta qualità è un compito molto difficile. Il problema non è nella quantità di codice, ma nel garantire un comportamento corretto e nelle difficoltà nell'implementazione delle interfacce, tenendo conto dell'enorme livello di applicazioni mai scritte in C/C++, così come di applicazioni in altri linguaggi, il cui runtime viene utilizzato di Libc. Un approccio frontale senza tener conto delle sfumature porterà solo al fatto che molti programmi esistenti non saranno in grado di funzionare con Libc, ma un progetto del genere non interesserà i consumatori.
• Lo sviluppo aziendale può rovinare Libc, ma spingerlo verso un uso diffuso, con conseguente necessità di aggiungere hack per garantire la compatibilità delle applicazioni. Lo sviluppo sotto l'egida di un progetto open source aziendale getterà la coperta verso i bisogni e le soluzioni dell'azienda, a scapito degli interessi della comunità. Ad esempio, se si identifica un problema causato da un bug in un altro programma, nello sviluppo controllato è più semplice assicurarsi che Libc sia compatibile con questo bug piuttosto che correggere il bug stesso. Apple utilizza il fork BSD libc per questi scopi e Google utilizza il fork musl in Fuchsia. L'esperienza dello sviluppatore musl è che è stato contattato principalmente da avvocati per chiarire questioni di licenza, ma non è mai stato contattato per chiarire dettagli tecnici prima di apportare modifiche inutili e distruttive ai suoi rami.
• L'assenza di una monocultura nello sviluppo di libc e l'attenzione agli standard guidati dal consenso piuttosto che al controllo individuale, che motiva gli sviluppatori di applicazioni a utilizzare gli standard piuttosto che essere legati a implementazioni specifiche. Questo è il motivo per cui l'autore di musl è contrario all'inclusione della sua libreria in LLVM, così come allo sviluppo di libc all'interno di LLVM, poiché in questo caso si perde la natura indipendente di libc e una certa implementazione diventa una soluzione di prima classe per LLVM e tutti gli altri diventano una soluzione di seconda classe.

Fonte: opennet.ru