Google иштеп чыгуучулардын бири LLVM долбоорунун бир бөлүгү катары көп платформалуу стандарттык C китепканасын (Libc) иштеп чыгуу жөнүндө LLVM почта тизмесинде. Бир катар себептерден улам, Google учурдагы libc (glibc, musl) менен канааттанбайт жана компания LLVMдин бир бөлүгү катары иштелип чыгуусу сунушталган жаңы ишке ашыруунун жолунда.
LLVM иштеп чыгуулары жакында Google'дун монтаждоо куралдарын куруу үчүн негиз катары колдонулду. Негизги идея, эгерде Google өзүнүн libc-сын иштеп чыга баштаган болсо, анда эмне үчүн дароо эле C++ (Libc++) үчүн өзүнүн стандарттуу китепканасын сунуштаган LLVMдин бир бөлүгү катары өз системасын иштеп чыгууга болбойт, бирок C үчүн окшош стандарттуу китепкана жок. (libc).
Иштеп чыгууну этап-этабы менен жүргүзүү пландаштырылууда, акырындык менен функционалдуулук жогорулайт. Биринчи варианттарды тиркеме менен Libc тутумунун ортосундагы катмар катары долбоорлоо сунушталат, алардан али ишке ашырыла элек функциялар алынат. Белгилүү бир функциялык деңгээлге жеткенден кийин, жаңы Libc Libc тутумун толук алмаштыруучу катары колдонулушу мүмкүн. Биз x86-64 архитектурасын, Linux жана статикалык байланышты колдоо менен баштоону пландап жатабыз (динамикалык жүктөө, шилтемелөө жана кошумча архитектура экинчи ирет ишке ашырылат).
Долбоор дагы эле иштеп чыгуунун баштапкы этабында, бирок негизги максаттары аныкталган:
- Модулдуулук жана монолиттүү жыйнакка караганда гранулдуу китепкананы жеткирүү философиясына ылайык өнүгүү;
- Режимдерде статикалык байланышты колдоо (Позицияга көз карандысыз аткарылуучу файлдар) жана PIE жок. Статикалык байланышкан аткарылуучу файлдар үчүн CRT (C Runtime) жана PIE жүктөгүч менен камсыз кылуу;
- POSIX кошумчалары жана учурдагы тиркемелер тарабынан талап кылынган кээ бир системага тиешелүү кеңейтүүлөр менен стандарттык C китепканасынын функцияларынын көпчүлүгүн колдоо;
- Сатуучуга тиешелүү кеңейтүүлөрдөн этият болуңуз жана аларды зарыл болгондо гана кошуңуз. Үчүнчү тараптын кеңейтүүлөрүн колдоо боюнча, Clang жана libc++ долбоорлорунун ыкмасын колдонуу сунушталат;
- LLVM инструменттерин колдонуу менен иштеп чыгууда эң мыкты тажрыйбаларды колдонуу, мисалы, дезинфекциялоочу каражатты жана fuzz тестин башынан эле колдонуу.
активдүү LLVM иштеп чыгуучулардын бири Libcти LLVM инструменттеринин бир бөлүгү катары жеткирүү мааниси бар экени түшүнүктүү, бирок, адатта, мындай муктаждык пайда болгондо, алар жакшы жазылган, ар кандай архитектураларды колдогон жана динамикалык колдоону кошкондо, керектүү функцияларды камсыз кылган musl китепканасын колдонушат. байланыштыруу. LLVMге musl киргизүү жана аны негизги долбоор менен синхрондуу айры катары иштеп чыгуу негиздүү болушу мүмкүн.
Сиздин да пикириңиз Musl долбоорунун автору, эмне үчүн Google сунушу жана Libcди LLVM бөлүштүрүүгө киргизүү абдан жаман идеялар экенин талашууга аракет кылган:
- Туура, шайкеш жана жогорку сапаттагы Libcти иштеп чыгуу жана колдоо абдан татаал иш. Маселе коддун көлөмүндө эмес, туура жүрүм-турумду камсыз кылууда жана C/C++ тилдеринде мурда жазылган тиркемелердин эбегейсиз катмарын, ошондой эле иштөө убактысы колдонулган башка тилдердеги тиркемелерди эске алуу менен интерфейстерди ишке ашыруудагы кыйынчылыктарда. Libc тарабынан. Нюанстарды эсепке албастан, бетме-бет мамиле жасоо көптөгөн учурдагы программалар Libc менен иштей албай калышына алып келет, бирок анда мындай долбоор керектөөчүлөрдү кызыктырбайт.
- Корпоративдик өнүгүү Libcти кыйратышы мүмкүн, бирок аны кеңири колдонууга түртөт, натыйжада колдонмолордо шайкештикти камсыз кылуу үчүн хакерлерди кошуу керек. Корпоративдик ачык булактуу долбоордун алкагында иштеп чыгуу коомчулуктун кызыкчылыктарына зыян келтирип, компаниянын муктаждыктарына жана чечимдерине жууркан тартат. Мисалы, башка программадагы мүчүлүштүктөн келип чыккан көйгөйдү аныктасаңыз, башкарылуучу иштеп чыгууда мүчүлүштүктүн өзүн оңдоого караганда Libc бул мүчүлүштүк менен шайкеш келээрин текшерүү оңой. Бул максаттар үчүн Apple BSD libc айрысын, ал эми Google Фуксияда musl айрысын колдонот. Мусулмандык иштеп чыгуучунун тажрыйбасы, лицензиялоо маселелерин тактоо үчүн ага негизинен юристтер кайрылышкан, бирок анын бутактарына пайдасыз жана үзгүлтүксүз өзгөртүүлөрдү киргизүүдөн мурун техникалык деталдарды тактоо үчүн эч качан байланышкан эмес.
- libc өнүктүрүүдө монокультуранын жоктугу жана жеке көзөмөлгө эмес, консенсуска негизделген стандарттарга басым жасоо, бул тиркемени иштеп чыгуучуларды конкреттүү ишке ашырууга байланбастан, стандарттарды колдонууга түрткү берет. Ошондуктан musl автору өзүнүн китепканасын LLVMге киргизүүгө каршы, ошондой эле LLVM ичинде libc өнүктүрүүгө каршы, анткени бул учурда libcтин көз карандысыз мүнөзү жоголуп, белгилүү бир ишке ашыруу биринчи класстагы чечимге айланат. LLVM жана башкалар экинчи класстагы чечимге айланат.
Source: opennet.ru