Google-dan tərtibatçılardan biri LLVM layihəsinin bir hissəsi kimi çox platformalı standart C kitabxanasının (Libc) inkişafı haqqında LLVM poçt siyahısında. Bir sıra səbəblərə görə, Google hazırkı libc (glibc, musl) ilə kifayətlənmir və şirkət LLVM-in bir hissəsi kimi hazırlanması təklif olunan yeni tətbiqetmənin hazırlanması yolundadır.
LLVM inkişafları bu yaxınlarda Google-un montaj alətlərinin qurulması üçün əsas kimi istifadə edilmişdir. Əsas ideya ondan ibarətdir ki, əgər Google artıq öz libc-sini inkişaf etdirməyə başlayıbsa, niyə də sistemini C++ (Libc++) üçün artıq öz standart kitabxanasını təklif edən, lakin C üçün oxşar standart kitabxanası olmayan LLVM-nin bir hissəsi kimi dərhal inkişaf etdirməyəsən. (libc).
İnkişafın mərhələlərlə həyata keçirilməsi, funksionallığın tədricən artırılması planlaşdırılır. İlk variantların tətbiqetmə ilə Libc sistemi arasında bir təbəqə kimi dizayn edilməsi təklif olunur, ondan hələ həyata keçirilməmiş funksiyalar götürüləcək. Müəyyən funksionallıq səviyyəsinə çatdıqdan sonra yeni Libc sistemi Libc üçün tam əvəz kimi istifadə edilə bilər. Biz x86-64 arxitekturası, Linux və statik əlaqələndirmə dəstəyi ilə başlamağı planlaşdırırıq (dinamik yükləmə, əlaqələndirmə və əlavə arxitekturalar ikinci olaraq həyata keçiriləcək).
Layihə hələ inkişafın ilkin mərhələsindədir, lakin əsas məqsədlər artıq müəyyən edilib:
- Monolit dəstdən daha çox dənəvər kitabxana təqdim etmək fəlsəfəsinə uyğun modulluq və inkişaf;
- Rejimlərdə statik keçid üçün dəstək (Mövqedən asılı olmayan icra sənədləri) və PIE olmadan. Statik olaraq əlaqəli icra olunanlar üçün CRT (C iş vaxtı) və PIE yükləyicisinin təmin edilməsi;
- POSIX əlavələri və mövcud proqramlar tərəfindən tələb olunan bəzi sistem-xüsusi genişləndirmələrlə standart C kitabxana funksiyalarının əksəriyyətinə dəstək;
- Satıcıya məxsus genişləndirmələrlə diqqətli olun və onları yalnız lazım olduqda əlavə edin. Üçüncü tərəf uzantılarının dəstəyinə gəldikdə, Clang və libc++ layihələrinin yanaşmasından istifadə etmək təklif olunur;
- LLVM alət dəstindən istifadə edərək inkişafda ən yaxşı təcrübələrdən istifadə etmək, məsələn, təmizləyici vasitələrdən istifadə və lap əvvəldən fuzz testi.
Aktiv LLVM tərtibatçılarından biri Aydındır ki, libc-ni LLVM alət dəstinin bir hissəsi kimi göndərməyin mənası var, lakin adətən, belə bir ehtiyac yarandıqda, onlar yaxşı yazılmış, müxtəlif arxitekturaları dəstəkləyən və lazımi funksionallığı təmin edən musl kitabxanasından istifadə edirlər. əlaqələndirir. Musl-ı LLVM-ə yerləşdirmək və onu əsas layihə ilə sinxronlaşdırılmış çəngəl kimi inkişaf etdirmək əsaslandırıla bilər.
Sizin də fikrinizi Google-un təklifi və Libc-in LLVM paylanmasına daxil edilməsinin niyə çox pis fikirlər olduğunu mübahisə etməyə çalışan Musl layihəsinin müəllifi:
- Düzgün, uyğun və yüksək keyfiyyətli Libc-nin hazırlanması və saxlanması çox çətin bir işdir. Problem kodun miqdarında deyil, C/C++-da indiyədək yazılmış nəhəng tətbiqlər təbəqəsini, eləcə də icra müddəti istifadə olunan digər dillərdəki proqramları nəzərə alaraq, düzgün davranışın və interfeyslərin həyata keçirilməsində çətinliklərin təmin edilməsindədir. Libc tərəfindən. Nüansları nəzərə almadan birbaşa yanaşma yalnız bir çox mövcud proqramların Libc ilə işləyə bilməyəcəyinə gətirib çıxaracaq, lakin sonra belə bir layihə istehlakçılar üçün maraqlı olmayacaq.
- Korporativ inkişaf Libc-i məhv edə bilər, lakin onu geniş istifadəyə sövq edir, nəticədə tətbiqlərdə uyğunluğu təmin etmək üçün hacklər əlavə etmək lazımdır. Korporativ açıq mənbə layihəsinin himayəsi altında inkişaf cəmiyyətin maraqlarına zərər verərək, şirkətin ehtiyacları və həlləri istiqamətində yorğanı çəkəcək. Məsələn, başqa bir proqramdakı səhvin səbəb olduğu problemi müəyyən etsəniz, idarə olunan inkişafda Libc-nin bu səhvlə uyğun olmasını təmin etmək səhvin özünü düzəltməkdən daha asandır. Apple bu məqsədlər üçün BSD libc çəngəlindən, Google isə Fuşyada musl çəngəlindən istifadə edir. Musl developerinin təcrübəsi ondan ibarətdir ki, lisenziyalaşdırma məsələlərini aydınlaşdırmaq üçün onunla əsasən hüquqşünaslar əlaqə saxlayıb, lakin filiallarında faydasız və pozucu dəyişikliklər etməzdən əvvəl texniki detalları aydınlaşdırmaq üçün heç vaxt əlaqə saxlamayıb.
- Libc inkişafında monokulturanın olmaması və fərdi nəzarətdən daha çox konsensusa əsaslanan standartlara diqqət yetirilməsi, proqram tərtibatçılarını xüsusi tətbiqlərə bağlı olmaqdansa, standartlardan istifadə etməyə sövq edir. Məhz buna görə də musl müəllifi öz kitabxanasının LLVM-ə daxil edilməsinin əleyhinədir, eləcə də libc-nin LLVM daxilində inkişafına qarşıdır, çünki bu halda libc-nin müstəqil təbiəti itirilir və müəyyən həyata keçirilməsi birinci dərəcəli həll yoluna çevrilir. LLVM və digərləri ikinci dərəcəli həllə çevrilir.
Mənbə: opennet.ru