Google-ийн хөгжүүлэгчдийн нэг LLVM төслийн хүрээнд олон платформ стандарт C номын сан (Libc) хөгжүүлэх тухай LLVM захидлын жагсаалтад. Хэд хэдэн шалтгааны улмаас Google одоогийн libc (glibc, musl) -д сэтгэл хангалуун бус байгаа бөгөөд компани нь LLVM-ийн нэг хэсэг болгон хөгжүүлэхийг санал болгож буй шинэ хэрэгжилтийг боловсруулах замдаа явж байна.
Саяхан LLVM хөгжүүлэлтүүд нь Google-ийн угсралтын хэрэгслүүдийг бий болгох үндэс болгон ашиглаж байна. Гол санаа нь хэрвээ Google аль хэдийн libc-ээ хөгжүүлж эхэлсэн бол C++ (Libc++)-д зориулсан өөрийн стандарт номын санг санал болгож буй LLVM-ийн нэг хэсэг болгон системээ нэн даруй хөгжүүлж яагаад болохгүй гэж? (libc).
Бүтээн байгуулалтыг үе шаттайгаар хийж, функциональ байдлыг аажмаар нэмэгдүүлэхээр төлөвлөж байна. Эхний сонголтуудыг программ болон Libc системийн хооронд давхарга хэлбэрээр зохион бүтээхийг санал болгож байгаа бөгөөд үүнээс хараахан хэрэгжээгүй байгаа функцуудыг зээлж авах болно. Үйл ажиллагааны тодорхой түвшинд хүрсэний дараа шинэ Libc-ийг Libc системийг бүрэн орлуулах боломжтой. Бид x86-64 архитектур, Линукс, статик холболтыг (динамик ачаалах, холбох, нэмэлт архитектуруудыг хоёрдогч байдлаар хэрэгжүүлэх болно) дэмжлэгтэйгээр эхлүүлэхээр төлөвлөж байна.
Төсөл нь хөгжлийн эхний шатандаа байгаа боловч үндсэн зорилтуудыг аль хэдийн тодорхойлсон байна.
- Цул номын сангаас илүүтэйгээр бөөгнөрсөн номын сан хүргэх философийн дагуу модульчлагдсан байдал, хөгжил;
- Горим дахь статик холболтыг дэмжих (Байрлалаас хамааралгүй гүйцэтгэгдэх файлууд) ба PIE-гүй. Статик холболттой гүйцэтгэх файлуудад зориулсан CRT (C runtime) болон PIE дуудагчаар хангах;
- POSIX нэмэлтүүд болон одоо байгаа програмуудад шаардлагатай зарим системийн тусгай өргөтгөлүүд бүхий стандарт C номын сангийн ихэнх функцийг дэмжих;
- Худалдагчийн тусгай өргөтгөлүүдийг болгоомжтой байгаарай, шаардлагатай үед л нэмнэ үү. Гуравдагч этгээдийн өргөтгөлүүдийг дэмжих тухайд Clang болон libc++ төслүүдийн хандлагыг ашиглахыг санал болгож байна;
- Ариутгагч бодис, fuzz тестийг эхнээс нь ашиглах гэх мэт LLVM хэрэгслийн хэрэгслийг ашиглан хөгжүүлэлтийн шилдэг туршлагуудыг ашиглах.
LLVM-ийн идэвхтэй хөгжүүлэгчдийн нэг Libc-г LLVM хэрэгслийн нэг хэсэг болгон тээвэрлэх нь ойлгомжтой боловч ихэвчлэн ийм хэрэгцээ гарвал сайн бичигдсэн, янз бүрийн архитектурыг дэмждэг, динамикийг дэмжих зэрэг шаардлагатай функцээр хангадаг musl номын санг ашигладаг. холбох. LLVM-д musl суулгаж, үндсэн төсөлтэй синхрончлогдсон сэрээ болгон хөгжүүлэх нь үндэслэлтэй байж болох юм.
Таны санал бас Google-ийн санал болон LLVM түгээлтэд Libc-ийг оруулах нь яагаад маш муу санаа болохыг маргахыг оролдсон Musl төслийн зохиогч:
- Зөв, нийцтэй, өндөр чанартай Libc-г хөгжүүлж, хадгалах нь маш хэцүү ажил юм. Асуудал нь кодын хэмжээнд биш, харин C/C++ хэл дээр бичигдсэн асар их хэмжээний программ хангамж, түүнчлэн ажиллах хугацаа нь ашиглагддаг бусад хэл дээрх програмуудыг харгалзан зөв ажиллах, интерфэйсийг хэрэгжүүлэхэд хүндрэлтэй байгаа явдал юм. Libc. Нарийн ялгааг харгалзахгүйгээр шууд хандах нь одоо байгаа олон программууд Libc-тэй ажиллах боломжгүй болоход хүргэдэг, гэхдээ ийм төсөл нь хэрэглэгчдийн сонирхлыг татахгүй байх болно.
- Корпорацийн хөгжил нь Libc-ийг сүйрүүлж болох ч өргөн хэрэглээнд түлхэц өгч, программуудын нийцтэй байдлыг хангахын тулд хакеруудыг нэмэх шаардлагатай болдог. Корпорацийн нээлттэй эхийн төслийн ивээл дор бүтээн байгуулалт хийх нь тухайн компанийн хэрэгцээ, шийдэл рүү чиглэж, олон нийтийн эрх ашгийг хохироох болно. Жишээлбэл, хэрэв та өөр програмын алдаанаас үүссэн асуудлыг олж мэдсэн бол хяналттай хөгжүүлэлтийн үед Libc-ийг энэ алдаатай нийцэж байгаа эсэхийг шалгах нь алдааг өөрөө засахаас илүү хялбар байдаг. Эдгээр зорилгоор Apple нь BSD libc сэрээ ашигладаг бол Google нь Фуксиа дахь musl сэрээг ашигладаг. Мусл хөгжүүлэгчийн туршлагаас харахад лицензийн асуудлыг тодруулахын тулд хуульчид голчлон холбогдож байсан боловч салбарууддаа ашиггүй, тасалдалтай өөрчлөлт хийхээс өмнө техникийн нарийн ширийн зүйлийг тодруулахаар хэзээ ч холбоо бариагүй.
- libc-ийн хөгжилд моно соёл байхгүй, хувь хүний хяналтаас илүү зөвшилцөлд тулгуурласан стандартад анхаарлаа төвлөрүүлж байгаа нь програм хөгжүүлэгчдийг тодорхой хэрэгжилттэй уялдуулахын оронд стандартыг ашиглах сэдэл төрүүлдэг. Тийм ч учраас musl-ийн зохиогч өөрийн номын санг LLVM-д оруулахын эсрэг, мөн LLVM доторх libc-ийг хөгжүүлэхийн эсрэг байна, учир нь энэ тохиолдолд libc-ийн бие даасан шинж чанар алдагдаж, тодорхой хэрэгжилт нь нэгдүгээр зэрэглэлийн шийдэл болж хувирдаг. LLVM болон бусад нь хоёр дахь зэрэглэлийн шийдэл болж хувирдаг.
Эх сурвалж: opennet.ru