Usa sa mga developers gikan sa Google sa LLVM mailing list mahitungod sa pagpalambo sa usa ka multi-platform standard C library (Libc) isip kabahin sa proyekto sa LLVM. Alang sa daghang mga hinungdan, ang Google wala matagbaw sa karon nga libc (glibc, musl) ug ang kompanya nagpaingon sa pag-uswag sa usa ka bag-ong implementasyon, nga gisugyot nga pauswagon ingon bahin sa LLVM.
Ang mga kalambuan sa LLVM bag-o lang gigamit isip sukaranan sa pagtukod sa mga himan sa asembliya sa Google. Ang nag-unang ideya mao nga kung ang Google nagsugod na sa pagpalambo sa iyang libc, nan nganong dili dayon sa pagpalambo sa iyang sistema isip bahin sa LLVM, nga nagtanyag na sa iyang kaugalingong standard library para sa C++ (Libc++), apan walay susama nga standard library para sa C (libc).
Ang pag-uswag giplano nga himuon sa mga yugto, anam-anam nga pagdugang sa pag-andar. Ang una nga mga kapilian gisugyot nga gidisenyo ingon usa ka layer sa taliwala sa aplikasyon ug sa sistema nga Libc, diin ang mga bahin nga wala pa gipatuman pagahulaman. Human sa pagkab-ot sa usa ka piho nga lebel sa pagpaandar, ang bag-ong Libc mahimong gamiton isip usa ka kompleto nga kapuli sa sistema nga Libc. Nagplano kami nga magsugod uban ang suporta alang sa x86-64 nga arkitektura, Linux, ug static nga pag-link (dinamikong pagkarga, pag-link, ug dugang nga mga arkitektura ipatuman sa ikaduha).
Ang proyekto naa pa sa inisyal nga yugto sa pag-uswag, apan ang sukaranan nga mga katuyoan gihubit na:
- Modularity ug kalamboan subay sa pilosopiya sa paghatod sa usa ka granular librarya kay sa usa ka monolithic set;
- Suporta alang sa static nga pag-link sa mga mode (Position-independent executables) ug walay PIE. Paghatag CRT (C runtime) ug PIE loader alang sa statically linked executables;
- Suporta alang sa kadaghanan sa mga standard nga C library function, nga adunay mga pagdugang sa POSIX ug pipila ka mga extension nga espesipiko sa sistema nga gikinahanglan sa kasamtangan nga mga aplikasyon;
- Pag-amping sa mga extension nga espesipiko sa vendor ug idugang lang kini kung gikinahanglan. Mahitungod sa suporta alang sa mga extension sa ikatulo nga partido, gisugyot nga gamiton ang pamaagi sa mga proyekto sa Clang ug libc++;
- Paggamit sa labing maayo nga mga gawi sa pag-uswag gamit ang LLVM toolkit, sama sa paggamit sa sanitizer ug fuzz testing gikan sa sinugdanan.
Usa sa mga aktibo nga developer sa LLVM Klaro nga makatarunganon nga ipadala ang libc isip bahin sa toolkit sa LLVM, apan kasagaran, kung adunay ingon nga panginahanglanon, gigamit nila ang musl library, nga maayo ang pagkasulat, nagsuporta sa lainlaing mga arkitektura, ug naghatag kinahanglan nga gamit, lakip ang suporta alang sa dinamikong. pagsumpay. Mahimong makatarunganon nga i-embed ang musl sa LLVM ug i-develop kini ingon usa ka tinidor nga gi-synchronize sa panguna nga proyekto.
Ang imong opinyon usab Ang tagsulat sa proyekto sa Musl, nga misulay sa paglalis ngano nga ang sugyot sa Google ug ang paglakip sa Libc sa pag-apod-apod sa LLVM daotan kaayo nga mga ideya:
- Ang pagpalambo ug pagmentinar sa husto, katugbang, ug taas nga kalidad nga Libc usa ka lisud kaayo nga buluhaton. Ang problema dili sa kantidad sa code, apan sa pagsiguro sa husto nga pamatasan ug mga kalisud sa pagpatuman sa mga interface, nga gikonsiderar ang dako nga layer sa mga aplikasyon nga gisulat sa C / C ++, ingon man mga aplikasyon sa ubang mga pinulongan, ang runtime nga gigamit. pinaagi sa Libc. Ang usa ka head-on nga pamaagi nga wala magtagad sa mga nuances magdala lamang sa kamatuoran nga daghang mga kasamtangan nga mga programa ang dili makahimo sa pagtrabaho uban sa Libc, apan ang ingon nga proyekto dili interesado sa mga konsumedor.
- Ang pagpalambo sa korporasyon mahimong makaguba sa Libc, apan iduso kini alang sa kaylap nga paggamit, nga moresulta sa panginahanglan sa pagdugang sa mga hack aron masiguro ang pagkaangay sa mga aplikasyon. Ang pag-uswag ubos sa pagdumala sa usa ka corporate open source nga proyekto mobira sa habol ngadto sa mga panginahanglan ug mga solusyon sa kompanya, nga makadaot sa interes sa komunidad. Pananglitan, kung nahibal-an nimo ang usa ka problema nga gipahinabo sa usa ka bug sa lain nga programa, sa kontrolado nga pag-uswag mas dali nga masiguro nga ang Libc nahiuyon sa kini nga bug kaysa sa pag-ayo sa bug mismo. Gigamit sa Apple ang BSD libc fork alang niini nga mga katuyoan, ug gigamit sa Google ang musl fork sa Fuchsia. Ang kasinatian sa musl developer mao nga siya gikontak nag-una sa mga abogado aron sa pagpatin-aw sa mga isyu sa paglilisensya, apan wala gayud makontak aron sa pagpatin-aw sa teknikal nga mga detalye sa wala pa maghimo sa walay pulos ug makabalda nga mga kausaban sa iyang mga sanga.
- Ang pagkawala sa usa ka monoculture sa libc development ug usa ka focus sa consensus-driven nga mga sumbanan kay sa indibidwal nga kontrol, nga nag-aghat sa mga developers sa aplikasyon sa paggamit sa mga sumbanan kay sa gihigot sa piho nga mga pagpatuman. Mao nga ang tagsulat sa musl supak sa paglakip sa iyang librarya sa LLVM, ingon man batok sa pag-uswag sa libc sulod sa LLVM, tungod kay sa kini nga kaso nawala ang independente nga kinaiya sa libc ug ang usa ka piho nga pagpatuman nahimo nga usa ka una nga klase nga solusyon alang sa Ang LLVM, ug ang uban pa nahimong ikaduha nga klase nga solusyon.
Source: opennet.ru