Hönnuðir frá Google lögðu til að þróa eigin libc fyrir LLVM

Einn af forriturunum frá Google hækkaði á póstlista LLVM um þróun fjölvettvangs staðlaðs C bókasafns (Libc) sem hluta af LLVM verkefninu. Af ýmsum ástæðum er Google ekki sátt við núverandi libc (glibc, musl) og fyrirtækið er á leiðinni að þróa nýja útfærslu sem lagt er til að verði þróuð sem hluti af LLVM.

Þróun LLVM hefur nýlega verið notuð sem grunnur til að byggja upp samsetningarverkfæri Google. Meginhugmyndin er sú að ef Google hefur þegar byrjað að þróa libc sitt, hvers vegna þá ekki strax að þróa kerfið sitt sem hluta af LLVM, sem býður nú þegar upp á sitt eigið staðlaða bókasafn fyrir C++ (Libc++), en er ekki með svipað staðlað bókasafn fyrir C (libc).

Fyrirhugað er að þróunin fari fram í áföngum og eykur virkni smám saman. Lagt er til að fyrstu valkostirnir verði hannaðir sem lag á milli forritsins og Libc kerfisins, þar sem eiginleikar sem ekki hafa enn verið innleiddir verða fengnir að láni. Eftir að hafa náð ákveðnu virknistigi er hægt að nota nýja Libc sem fullkominn staðgengil fyrir Libc kerfið. Við ætlum að byrja með stuðning fyrir x86-64 arkitektúr, Linux og kyrrstæða tengingu (kvikhleðsla, tenging og viðbótararkitektúr verða innleidd í öðru lagi).

Verkefnið er enn á frumstigi þróunar, en grunnmarkmið hafa þegar verið skilgreind:

  • Einingakerfi og þróun í samræmi við hugmyndafræðina um að afhenda kornótt bókasafn frekar en einhæft sett;
  • Stuðningur við truflanir tengingar í stillingum BAKA (Stöðuóháð executables) og án PIE. Að útvega CRT (C keyrslutíma) og PIE hleðslutæki fyrir statískt tengd keyrsluefni;
  • Stuðningur við flestar staðlaðar C bókasafnsaðgerðir, með POSIX viðbótum og sumum kerfissértækum viðbótum sem fyrirliggjandi forrit þurfa;
  • Vertu varkár með söluaðila-sértækar viðbætur og bættu þeim aðeins við þegar þörf krefur. Varðandi stuðning við viðbætur frá þriðja aðila er lagt til að nota nálgun Clang og libc++ verkefnin;
  • Notkun bestu starfsvenja við þróun með því að nota LLVM verkfærakistuna, svo sem að nota hreinsiefni og fuzzpróf frá upphafi.

Einn af virku LLVM verktaki benti áÞað er ljóst að það er skynsamlegt að senda libc sem hluta af LLVM verkfærakistunni, en venjulega, þegar slík þörf kemur upp, nota þeir musl bókasafnið, sem er vel skrifað, styður ýmsa arkitektúr og veitir nauðsynlega virkni, þar á meðal stuðning fyrir kraftmikla tengja. Það getur verið réttlætanlegt að fella musl inn í LLVM og þróa það sem gaffal samstilltan við aðalverkefnið.

Þín skoðun líka fram Höfundur Musl verkefnisins, sem reyndi að færa rök fyrir því hvers vegna tillaga Google og upptaka Libc í LLVM dreifingunni eru mjög slæmar hugmyndir:

  • Það er mjög erfitt verkefni að þróa og viðhalda réttri, samhæfri og hágæða Libc. Vandamálið felst ekki í magni kóða, heldur í því að tryggja rétta hegðun og erfiðleika við innleiðingu viðmóta, að teknu tilliti til þess mikla lags forrita sem nokkru sinni hefur verið skrifað í C/C++, sem og forritum á öðrum tungumálum, sem keyrslutími er notaður. eftir Libc. Höfuð nálgun án þess að taka tillit til blæbrigða mun aðeins leiða til þess að mörg núverandi forrit munu ekki geta unnið með Libc, en þá mun slíkt verkefni ekki vera áhugavert fyrir neytendur.
  • Fyrirtækjaþróun getur eyðilagt Libc, en ýtt á það fyrir víðtæka notkun, sem leiðir til þess að bæta þarf við járnsög til að tryggja eindrægni í forritum. Þróun undir merkjum opins hugbúnaðarverkefnis mun draga sængina í átt að þörfum og lausnum fyrirtækisins, í óhag fyrir hagsmuni samfélagsins. Til dæmis, ef þú greinir vandamál sem stafar af villu í öðru forriti, í stýrðri þróun er auðveldara að tryggja að Libc sé samhæft við þessa villu en að laga villuna sjálfa. Apple notar BSD libc gaffalinn í þessum tilgangi og Google notar musl gaffalinn í Fuchsia. Reynsla musl framkvæmdaraðila er sú að lögfræðingar höfðu aðallega samband við hann til að skýra leyfismál, en aldrei var haft samband við hann til að skýra tæknilegar upplýsingar áður en ónýtar og truflandi breytingar voru gerðar á útibúum sínum.
  • Skortur á einmenningu í libc þróun og áhersla á samstöðu-drifna staðla frekar en einstaklingsstjórnun, sem hvetur forritara til að nota staðla frekar en að vera bundin við sérstakar útfærslur. Þess vegna er höfundur musl á móti því að bókasafn hans sé tekið upp í LLVM, sem og á móti þróun libc innan LLVM, þar sem í þessu tilviki glatast hið sjálfstæða eðli libc og ákveðin útfærsla verður fyrsta flokks lausn fyrir LLVM, og allir aðrir verða annars flokks lausn.

Heimild: opennet.ru

Bæta við athugasemd