Programeri iz Googlea su predložili razvoj vlastite libc za LLVM

Jedan od programera iz Google-a podignuta na LLVM mailing listi o razvoju višeplatformske standardne C biblioteke (Libc) kao dio LLVM projekta. Iz više razloga, Google nije zadovoljan trenutnom libc-om (glibc, musl) i kompanija je na putu da razvije novu implementaciju, za koju se predlaže da se razvije kao dio LLVM-a.

LLVM razvoji su nedavno korišteni kao osnova za izgradnju Googleovih alata za sklapanje. Glavna ideja je da ako je Google već počeo da razvija svoj libc, zašto onda ne bi odmah razvio svoj sistem kao dio LLVM-a, koji već nudi vlastitu standardnu ​​biblioteku za C++ (Libc++), ali nema sličnu standardnu ​​biblioteku za C (libc).

Planirano je da se razvoj odvija u fazama, postepeno povećavajući funkcionalnost. Predlaže se da prve opcije budu dizajnirane kao sloj između aplikacije i sistema Libc, iz kojeg će biti pozajmljene karakteristike koje još nisu implementirane. Nakon dostizanja određenog nivoa funkcionalnosti, novi Libc se može koristiti kao potpuna zamjena za sistem Libc. Planiramo da počnemo sa podrškom za x86-64 arhitekturu, Linux i statičko povezivanje (dinamičko učitavanje, povezivanje i dodatne arhitekture će biti implementirane sekundarno).

Projekat je još u početnoj fazi razvoja, ali su osnovni ciljevi već definisani:

• Modularnost i razvoj u skladu sa filozofijom isporuke granularne biblioteke, a ne monolitnog skupa;
• Podrška za statičko povezivanje u modovima pita (Izvršne datoteke neovisne o poziciji) i bez PIE. Pružanje CRT (C runtime) i PIE učitavača za statički povezane izvršne datoteke;
• Podrška za većinu standardnih funkcija C biblioteke, sa POSIX dodacima i nekim sistemskim ekstenzijama koje zahtijevaju postojeće aplikacije;
• Budite oprezni s ekstenzijama specifičnim za dobavljača i dodajte ih samo kada je potrebno. Što se tiče podrške za ekstenzije trećih strana, predlaže se korištenje pristupa Clang i libc++ projekata;
• Korištenje najboljih praksi u razvoju pomoću LLVM kompleta alata, kao što je korištenje sredstva za dezinfekciju i fuzz testiranje od samog početka.

Jedan od aktivnih LLVM programera istaknuoJasno je da ima smisla isporučiti libc kao dio LLVM alata, ali obično, kada se ukaže takva potreba, koriste musl biblioteku, koja je dobro napisana, podržava različite arhitekture i pruža potrebnu funkcionalnost, uključujući podršku za dinamičke povezivanje. Možda je opravdano ugraditi musl u LLVM i razviti ga kao viljušku sinhroniziranu s glavnim projektom.

Vaše mišljenje takođe izraženo Autor projekta Musl, koji je pokušao argumentirati zašto su Googleov prijedlog i uključivanje Libc-a u LLVM distribuciju vrlo loša ideja:

• Razvijanje i održavanje ispravnog, kompatibilnog i visokokvalitetnog Libc-a je vrlo težak zadatak. Problem nije u količini koda, već u osiguravanju ispravnog ponašanja i poteškoća u implementaciji interfejsa, uzimajući u obzir ogroman sloj aplikacija ikada napisanih na C/C++, kao i aplikacija na drugim jezicima čije se vrijeme izvršavanja koristi. od Libc. Pristup bez uzimanja u obzir nijansi samo će dovesti do činjenice da mnogi postojeći programi neće moći raditi s Libc-om, ali tada takav projekt neće biti od interesa za potrošače.
• Korporativni razvoj može uništiti Libc, ali ga gurnuti u široku upotrebu, što rezultira potrebom za dodavanjem hakova kako bi se osigurala kompatibilnost u aplikacijama. Razvoj pod okriljem korporativnog open source projekta povući će pokrivač prema potrebama i rješenjima kompanije, a na štetu interesa zajednice. Na primjer, ako identificirate problem koji je uzrokovan greškom u drugom programu, u kontroliranom razvoju lakše je osigurati da je Libc kompatibilan s ovom greškom nego popraviti samu grešku. Apple koristi BSD libc fork u ove svrhe, a Google koristi musl fork u Fuchsia. Iskustvo musl developera je da su ga uglavnom kontaktirali advokati kako bi razjasnili pitanja licenciranja, ali nikada nije kontaktiran da razjasni tehničke detalje prije nego što je napravio beskorisne i ometajuće promjene u svojim ograncima.
• Odsustvo monokulture u razvoju libc-a i fokus na standarde vođene konsenzusom, a ne na individualnu kontrolu, što motiviše programere aplikacija da koriste standarde, a ne da budu vezani za specifične implementacije. Zato je autor musl-a protiv uključivanja njegove biblioteke u LLVM, kao i protiv razvoja libc-a u okviru LLVM-a, jer se u ovom slučaju gubi nezavisna priroda libc-a i određena implementacija postaje prvoklasno rješenje za LLVM i svi ostali postaju drugorazredno rješenje.

izvor: opennet.ru