Unu di i sviluppatori di Google nantu à a lista di mailing LLVM nantu à u sviluppu di una libreria C standard multi-piattaforma (Libc) cum'è parte di u prughjettu LLVM. Per una quantità di motivi, Google ùn hè micca cuntentu di a libc attuale (glibc, musl) è a cumpagnia hè in strada per sviluppà una nova implementazione, chì hè pruposta per esse sviluppata cum'è parte di LLVM.
I sviluppi LLVM sò stati recentemente aduprati cum'è a basa per a custruzzione di l'arnesi di assemblea di Google. L'idea principale hè chì, se Google hà digià cuminciatu à sviluppà a so libc, allora perchè micca immediatamente u so sistema di sviluppu cum'è parte di LLVM, chì offre digià a so propria libreria standard per C++ (Libc++), ma ùn hà micca una biblioteca standard simili per C. (libc).
U sviluppu hè previstu per esse realizatu in tappe, aumentendu gradualmente a funziunalità. I primi opzioni sò pruposti per esse disignati cum'è una capa trà l'applicazione è u sistema Libc, da quale e funzioni chì ùn sò micca stati ancu implementate seranu prestitu. Dopu avè righjuntu un certu livellu di funziunalità, u novu Libc pò esse usatu cum'è un sustitutu cumpletu di u sistema Libc. Avemu pensatu à principià cù u supportu per l'architettura x86-64, Linux, è u ligame staticu (a carica dinamica, u ligame è l'architetture supplementari seranu implementate in secunna).
U prugettu hè sempre in una prima fase di sviluppu, ma i scopi basi sò digià definiti:
- Modularità è sviluppu in cunfurmità cù a filusufìa di furnisce una biblioteca granulare piuttostu cà un set monoliticu;
- Supportu per ligami statici in modi (Eseguibili indipendenti da a pusizione) è senza PIE. Fornisce CRT (C runtime) è caricatore PIE per eseguibili statichi ligati;
- Supportu per a maiò parte di e funzioni di libreria C standard, cù aghjunte POSIX è alcune estensioni specifiche di u sistema richieste da l'applicazioni esistenti;
- Attenti cù estensioni specifiche di u venditore è aghjunghje solu quandu hè necessariu. In quantu à u supportu per l'estensioni di terzu, hè prupostu di utilizà l'approcciu di i prughjetti Clang è libc++;
- Utilizendu e migliori pratiche in u sviluppu utilizendu u toolkit LLVM, cum'è l'usu di sanitizer è fuzz test da u principiu.
Unu di i sviluppatori LLVM attivi Hè chjaru chì hè sensu di spedinu libc cum'è parte di u toolkit LLVM, ma di solitu, quandu una tale necessità si presenta, usanu a libreria musl, chì hè ben scritta, sustene diverse architetture, è furnisce e funziunalità necessaria, cumpresu supportu per dinamica. liendu. Pò esse ghjustificatu per incrustà musl in LLVM è u sviluppu cum'è una furchetta sincronizata cù u prughjettu principale.
U vostru parè ancu L'autore di u prughjettu Musl, chì hà pruvatu à argumentà perchè a pruposta di Google è l'inclusione di Libc in a distribuzione LLVM sò idee assai male:
- Sviluppà è mantene un Libc currettu, cumpatibile è di alta qualità hè un compitu assai difficiule. U prublema ùn hè micca in a quantità di codice, ma in assicurà un cumpurtamentu currettu è difficultà in l'implementazione di l'interfaccia, tenendu in contu l'enorme strata di applicazioni mai scritte in C / C ++, è l'applicazioni in altre lingue, u runtime di quale hè utilizatu. da Libc. Un accostu di testa senza piglià in contu i sfumature solu porta à u fattu chì parechji prugrammi esistenti ùn puderanu micca travaglià cù Libc, ma allora un tali prughjettu ùn serà micca d'interessu per i cunsumatori.
- U sviluppu di l'impresa pò arruvinà Libc, ma u spinghje in un usu generalizatu, risultatu in a necessità di aghjunghje pirate per assicurà a cumpatibilità in l'applicazioni. U sviluppu sottu à l'auspice di un prughjettu di l'impresa open source tirarà a manta versu i bisogni è e suluzioni di a cumpagnia, à u detrimentu di l'interessi di a cumunità. Per esempiu, se identificate un prublema chì hè causatu da un bug in un altru prugramma, in u sviluppu cuntrullatu hè più faciule d'assicurà chì Libc hè cumpatibile cù questu bug cà di riparà u bug stessu. Apple usa a furchetta BSD libc per questi scopi, è Google usa a furchetta musl in Fuchsia. L'esperienza di u sviluppatore musl hè chì hè statu cuntattatu principarmenti da l'avucati per chjarificà i prublemi di licenze, ma ùn hè mai statu cuntattatu per clarificà i dettagli tecnichi prima di fà cambiamenti inutili è disruptive à i so rami.
- L'absenza di una monocultura in u sviluppu di libc è un focusu nantu à i normi cunsensuali piuttostu chè u cuntrollu individuale, chì motiva i sviluppatori di l'applicazioni à aduprà standard piuttostu ch'è esse ligatu à implementazioni specifiche. Hè per quessa chì l'autore di musl hè contru à l'inclusione di a so biblioteca in LLVM, è ancu contru à u sviluppu di libc in LLVM, postu chì in questu casu a natura indipendente di libc hè persa è una certa implementazione diventa una suluzione di prima classe per LLVM, è tutti l'altri diventanu una suluzione di seconda classe.
Source: opennet.ru