Unul dintre dezvoltatorii de la Google în lista de discuții LLVM tema dezvoltării unei biblioteci standard multiplatformă C (Libc) în cadrul proiectului LLVM. Din diverse motive, Google nu este mulțumit de bibliotecile libc existente (glibc, musl) și compania își propune dezvoltarea unei noi implementări, care va fi propusă pentru dezvoltare ca parte a LLVM.
Dezvoltările LLVM din ultima vreme sunt folosite ca bază pentru construirea instrumentarului Google. Ideea principală este că, dacă Google a început deja dezvoltarea propriei libc, de ce să nu își dezvolte direct sistemul ca parte a LLVM, care deja oferă propria bibliotecă standard pentru C++ (Libc++), dar nu are o bibliotecă standard similară pentru C (Libc).
Dezvoltarea este planificată să se desfășoare etapizat, crescând treptat funcționalitatea. Primele variante vor fi propuse sub forma unei straturi între aplicație și sistemul Libc, din care vor fi preluate funcționalitățile care nu sunt încă implementate. După atingerea unui anumit nivel de funcționalitate, noua Libc va putea fi utilizată ca o înlocuire completă a sistemului Libc. Se va începe cu suportul pentru arhitectura x86-64, Linux și legarea statică (încărcarea dinamică, legarea și arhitecturile suplimentare vor fi implementate în a doua etapă).
Proiectul este încă într-o etapă incipientă de dezvoltare, dar deja sunt definite obiectivele de bază:
- Modularitate și dezvoltare conform filozofiei furnizării unei biblioteci granulare, nu a unui set monolitic;
- Suport pentru legarea statică în moduri cu (executabile independente de poziție) și fără PIE. Furnizarea CRT (runtime C) și a unui încărcător PIE pentru fișierele executabile legate static;
- Suport pentru cea mai mare parte a funcțiilor bibliotecii standard C, cu adăugiri POSIX și unele extensii specifice sistemului, solicitate în aplicațiile existente;
- O abordare prudentă față de extensiile specifice furnizorilor și adăugarea acestora doar când este necesar. În ceea ce privește suportul pentru extensiile externe, se propune aplicarea abordării proiectelor Clang și libc++;
- Utilizarea celor mai bune practici în dezvoltare cu ajutorul instrumentarului LLVM, cum ar fi utilizarea sanitizatorilor și a testării prin fuzzing încă din primele etape.
Unul dintre dezvoltatorii activi ai LLVM , ceea ce face ca livrarea libc ca parte din instrumentele LLVM să aibă sens, dar de obicei, în astfel de situații, se utilizează biblioteca musl, care este bine scrisă, suportă diverse arhitecturi și oferă funcționalitatea necesară, inclusiv suport pentru legarea dinamică. Integrul musl în LLVM și dezvoltarea sa ca un fork sincronizat cu proiectul principal poate fi justificată.
De asemenea, și-a exprimat autorul proiectului Musl, care a încercat să argumenteze de ce propunerea Google de a include Libc în livrarea LLVM este o idee foarte proastă:
- Dezvoltarea și menținerea unei Libc corecte, compatibile și de înaltă calitate este o sarcină foarte dificilă. Problema nu constă în volumul de cod, ci în asigurarea unui comportament corect și dificultățile în implementarea interfețelor având în vedere imensitatea aplicațiilor scrise vreodată în C/C++, precum și a aplicațiilor în alte limbaje, a căror execuție utilizează Libc. O abordare brutală care ignoră nuanțele va conduce doar la faptul că multe programe existente nu vor reuși să funcționeze cu Libc, iar atunci un astfel de proiect nu va fi de interes pentru consumatori.
- Dezvoltarea corporativă poate deteriora Libc, dar poate fi impusă pentru utilizare extinsă, rezultând astfel necesitatea adăugării de hacks pentru a asigura compatibilitatea în aplicații. Dezvoltarea sub egida unui proiect corporatist deschis va trasa o direcție în funcție de nevoile și soluțiile companiei, în detrimentul intereselor comunității. De exemplu, în cazul în care se descoperă o problemă provocată de o eroare în altă aplicație deținuta de ei, în dezvoltarea controlată este mai ușor să se asigure compatibilitatea Libc cu această eroare decât să se corecteze eroarea în sine. Apple folosește pentru aceste scopuri un fork al BSD libc, iar Google aplică în Fuchsia un fork musl. Experiența dezvoltatorului musl arată că de obicei l-au contactat avocații pentru a clarifica întrebări legate de licențiere, dar niciodată nu s-au adresat pentru detalii tehnice înainte de a aduce în forks-urile lor modificări inutile și care deranjează funcționarea.
- Absența monoculturii în dezvoltarea libc și orientarea către standarde dezvoltate pe baza consensului, în loc de administrarea unilaterală, motivează dezvoltatorii de aplicații în să folosească standardele, și nu să se lege de implementări specifice. Acesta este motivul pentru care autorul musl se opune includerii bibliotecii sale în LLVM, la fel ca și împotriva dezvoltării libc în cadrul LLVM, deoarece în acest caz caracterul independent al libc se pierde, iar o anumită implementare devine soluția de primă clasă pentru LLVM, iar toate celelalte devin soluții de secundă clasă.
Sursa: opennet.ro
