Unul dintre dezvoltatorii de la Google pe lista de corespondență LLVM despre dezvoltarea unei biblioteci C standard multiplatformă (Libc) ca parte a proiectului LLVM. Din mai multe motive, Google nu este mulțumit de libc-ul actual (glibc, musl), iar compania este pe cale de a dezvolta o nouă implementare, care se propune să fie dezvoltată ca parte a LLVM.
Dezvoltarile LLVM au fost folosite recent ca bază pentru construirea instrumentelor de asamblare Google. Ideea principală este că, dacă Google a început deja să-și dezvolte libc, atunci de ce să nu își dezvolte imediat sistemul ca parte a LLVM, care oferă deja propria bibliotecă standard pentru C++ (Libc++), dar nu are o bibliotecă standard similară pentru C (libc).
Dezvoltarea este planificată să fie efectuată în etape, crescând treptat funcționalitatea. Primele opțiuni sunt propuse pentru a fi proiectate ca un strat între aplicație și sistemul Libc, din care vor fi împrumutate caracteristici care nu au fost încă implementate. După atingerea unui anumit nivel de funcționalitate, noul Libc poate fi folosit ca înlocuitor complet al sistemului Libc. Intenționăm să începem cu suport pentru arhitectura x86-64, Linux și legături statice (încărcarea dinamică, legăturile și arhitecturile suplimentare vor fi implementate secundar).
Proiectul este încă într-un stadiu incipient de dezvoltare, dar obiectivele de bază au fost deja definite:
- Modularitate și dezvoltare în conformitate cu filozofia furnizării unei biblioteci granulare mai degrabă decât a unui set monolitic;
- Suport pentru legarea statică în moduri (executabile independente de poziție) și fără PIE. Furnizarea CRT (C runtime) și încărcător PIE pentru executabile legate static;
- Suport pentru majoritatea funcțiilor standard de bibliotecă C, cu adăugiri POSIX și unele extensii specifice sistemului cerute de aplicațiile existente;
- Aveți grijă cu extensiile specifice furnizorului și adăugați-le numai atunci când este necesar. În ceea ce privește suportul pentru extensii terțe, se propune utilizarea abordării proiectelor Clang și libc++;
- Utilizarea celor mai bune practici în dezvoltare folosind setul de instrumente LLVM, cum ar fi utilizarea dezinfectantului și testarea fuzz de la bun început.
Unul dintre dezvoltatorii activi LLVM Este clar că are sens să livrăm libc ca parte a setului de instrumente LLVM, dar de obicei, atunci când apare o astfel de nevoie, ei folosesc biblioteca musl, care este bine scrisă, acceptă diferite arhitecturi și oferă funcționalitatea necesară, inclusiv suport pentru dinamica. legarea. Ar putea fi justificat să încorporați musl în LLVM și să îl dezvoltați ca un furk sincronizat cu proiectul principal.
si parerea ta Autorul proiectului Musl, care a încercat să argumenteze de ce propunerea Google și includerea Libc în distribuția LLVM sunt idei foarte proaste:
- Dezvoltarea și menținerea unui Libc corect, compatibil și de înaltă calitate este o sarcină foarte dificilă. Problema nu constă în cantitatea de cod, ci în asigurarea unui comportament corect și a dificultăților în implementarea interfețelor, ținând cont de stratul imens de aplicații scrise vreodată în C/C++, precum și de aplicații în alte limbaje, al căror timp de execuție este folosit. de Libc. O abordare frontală fără a ține cont de nuanțe va duce doar la faptul că multe programe existente nu vor putea funcționa cu Libc, dar atunci un astfel de proiect nu va fi de interes pentru consumatori.
- Dezvoltarea corporativă poate distruge Libc, dar îl poate împinge în utilizare pe scară largă, rezultând în necesitatea de a adăuga hack-uri pentru a asigura compatibilitatea în aplicații. Dezvoltarea sub auspiciile unui proiect corporativ open source va trage patura către nevoile și soluțiile companiei, în detrimentul intereselor comunității. De exemplu, dacă identificați o problemă care este cauzată de o eroare într-un alt program, în dezvoltarea controlată este mai ușor să vă asigurați că Libc este compatibil cu această eroare decât să remediați eroarea în sine. Apple folosește furca BSD libc în aceste scopuri, iar Google folosește furca musl în Fuchsia. Experiența dezvoltatorului musl este că a fost contactat în principal de avocați pentru a clarifica problemele de licențiere, dar nu a fost contactat niciodată pentru a clarifica detalii tehnice înainte de a face modificări inutile și perturbatoare la sucursalele sale.
- Absența unei monoculturi în dezvoltarea libc și concentrarea pe standardele bazate pe consens, mai degrabă decât pe controlul unic, ceea ce motivează dezvoltatorii de aplicații să folosească standarde mai degrabă decât să fie legați de implementări specifice. De aceea, autorul musl este împotriva includerii bibliotecii sale în LLVM, precum și împotriva dezvoltării libc în cadrul LLVM, deoarece în acest caz natura independentă a libc se pierde și o anumită implementare devine o soluție de primă clasă pentru LLVM și toate celelalte devin o soluție de clasa a doua.
Sursa: opennet.ru