Yksi Googlen kehittäjistä LLVM-postituslistalla monikäyttöisen standardin C-kirjaston (Libc) kehittämisestä osana LLVM-projektia. Useista syistä Google ei ole tyytyväinen nykyiseen libc:hen (glibc, musl) ja yritys on matkalla kehittämään uutta toteutusta, jota ehdotetaan kehitettävän osana LLVM:ää.
LLVM-kehitystä on viime aikoina käytetty perustana Googlen kokoonpanotyökalujen rakentamiseen. Pääajatuksena on, että jos Google on jo alkanut kehittää libc:ään, niin miksi ei heti kehittäisi järjestelmää osana LLVM:ää, joka tarjoaa jo omaa standardikirjastoa C++:lle (Libc++), mutta jolla ei ole vastaavaa standardikirjastoa C:lle. (libc).
Kehitys on suunniteltu tapahtuvaksi vaiheittain toimivuutta asteittain lisäämällä. Ensimmäiset vaihtoehdot ehdotetaan suunniteltavaksi sovelluksen ja Libc-järjestelmän väliin kerrokseksi, josta lainataan ominaisuuksia, joita ei ole vielä toteutettu. Kun uusi Libc on saavutettu tietyn toiminnallisuustason, sitä voidaan käyttää täydellisenä korvaajana Libc-järjestelmälle. Suunnittelemme aloittavamme x86-64-arkkitehtuurin, Linuxin ja staattisen linkityksen tuella (dynaaminen lataus, linkitys ja lisäarkkitehtuurit toteutetaan toissijaisesti).
Hanke on vielä alkuvaiheessa, mutta perustavoitteet on jo määritelty:
- Modulaarisuus ja kehitys sen filosofian mukaisesti, että toimitetaan rakeinen kirjasto monoliittisen sarjan sijaan;
- Staattisen linkityksen tuki tiloissa (Sijainnista riippumattomat suoritettavat tiedostot) ja ilman PIE:tä. CRT (C runtime) ja PIE-lataimen tarjoaminen staattisesti linkitetyille suoritettaville tiedostoille;
- Tuki useimpien standardien C-kirjastotoimintojen kanssa POSIX-lisäyksillä ja joillakin olemassa olevien sovellusten vaatimilla järjestelmäkohtaisilla laajennuksilla;
- Ole varovainen toimittajakohtaisten laajennusten kanssa ja lisää niitä vain tarvittaessa. Mitä tulee kolmansien osapuolien laajennusten tukeen, ehdotetaan Clang- ja libc++-projektien lähestymistapaa;
- Parhaiden käytäntöjen hyödyntäminen kehitystyössä LLVM-työkalupakin avulla, kuten desinfiointi- ja fuzz-testaus alusta alkaen.
Yksi aktiivisista LLVM-kehittäjistä On selvää, että on järkevää lähettää libc osana LLVM-työkalupakkia, mutta yleensä kun sellainen tarve ilmenee, he käyttävät musl-kirjastoa, joka on hyvin kirjoitettu, tukee erilaisia arkkitehtuureja ja tarjoaa tarvittavat toiminnot, mukaan lukien dynaamisen tuen. linkittäminen. Saattaa olla perusteltua upottaa musl LLVM:ään ja kehittää sitä haarukkaana, joka on synkronoitu pääprojektin kanssa.
Myös sinun mielipiteesi Musl-projektin kirjoittaja, joka yritti argumentoida, miksi Googlen ehdotus ja Libc:n sisällyttäminen LLVM-jakeluun ovat erittäin huonoja ideoita:
- Oikean, yhteensopivan ja laadukkaan Libc:n kehittäminen ja ylläpitäminen on erittäin vaikea tehtävä. Ongelma ei ole koodin määrässä, vaan oikean toiminnan varmistamisessa ja rajapintojen toteuttamisen vaikeuksissa, kun otetaan huomioon valtava C/C++-kielellä koskaan kirjoitettu sovelluskerros sekä muilla kielillä olevat sovellukset, joiden ajonaikaa käytetään. kirjoittanut Libc. Suoraviivainen lähestymistapa ottamatta huomioon vivahteita johtaa vain siihen, että monet nykyiset ohjelmat eivät pysty toimimaan Libc:n kanssa, mutta silloin tällainen projekti ei kiinnosta kuluttajia.
- Yrityskehitys voi pilata Libc:n, mutta työntää sen laajaan käyttöön, mikä johtaa tarpeeseen lisätä hakkereita sovellusten yhteensopivuuden varmistamiseksi. Yritysten avoimen lähdekoodin projektin alla tapahtuva kehitys vetää peiton yrityksen tarpeita ja ratkaisuja kohti yhteisön edun kustannuksella. Jos esimerkiksi tunnistat ongelman, joka johtuu toisessa ohjelmassa olevasta bugista, kontrolloidussa kehityksessä on helpompi varmistaa, että Libc on yhteensopiva tämän bugin kanssa, kuin korjata itse vika. Apple käyttää BSD libc -haarukkaa näihin tarkoituksiin, ja Google käyttää musl-haarukkaa fuksiassa. Musl-kehittäjän kokemus on, että häneen otettiin yhteyttä pääasiassa lakimiehiltä lisenssiongelmien selvittämiseksi, mutta häneen ei koskaan otettu yhteyttä teknisten yksityiskohtien selvittämiseksi ennen kuin hän teki hyödyttömiä ja häiritseviä muutoksia sivukonttoreihinsa.
- Monokulttuurin puuttuminen libc-kehityksessä ja keskittyminen konsensuslähtöisiin standardeihin yksilöllisen ohjauksen sijaan, mikä motivoi sovelluskehittäjiä käyttämään standardeja sen sijaan, että ne olisivat sidottu tiettyihin toteutuksiin. Tästä syystä muslin kirjoittaja vastustaa kirjastonsa sisällyttämistä LLVM:ään sekä libc:n kehittämistä LLVM:ssä, koska tässä tapauksessa libc:n itsenäinen luonne menetetään ja tietystä toteutuksesta tulee ensiluokkainen ratkaisu LLVM:stä ja kaikista muista tulee toisen luokan ratkaisu.
Lähde: opennet.ru