Google-ի մշակողներից մեկը LLVM փոստային ցուցակում, որը վերաբերում է բազմահարթակ ստանդարտ C գրադարանի (Libc) մշակմանը որպես LLVM նախագծի մաս: Մի շարք պատճառներով Google-ը բավարարված չէ ներկայիս libc-ով (glibc, musl) և ընկերությունը գտնվում է նոր ներդրման մշակման ճանապարհին, որն առաջարկվում է մշակել որպես LLVM-ի մաս։
LLVM-ի մշակումները վերջերս օգտագործվել են որպես Google-ի հավաքման գործիքների ստեղծման հիմք: Հիմնական գաղափարն այն է, որ եթե Google-ն արդեն սկսել է զարգացնել իր libc-ն, ապա ինչու անմիջապես չմշակել իր համակարգը որպես LLVM-ի մաս, որն արդեն առաջարկում է իր սեփական ստանդարտ գրադարանը C++-ի համար (Libc++), բայց չունի նմանատիպ ստանդարտ գրադարան C-ի համար։ (libc).
Մշակումը նախատեսվում է իրականացնել փուլերով՝ աստիճանաբար բարձրացնելով ֆունկցիոնալությունը։ Առաջին տարբերակներն առաջարկվում է նախագծվել որպես շերտ հավելվածի և Libc համակարգի միջև, որից փոխառվելու են դեռևս չներարկված գործառույթները։ Ֆունկցիոնալության որոշակի մակարդակի հասնելուց հետո նոր Libc-ը կարող է օգտագործվել որպես Libc համակարգի ամբողջական փոխարինում: Մենք նախատեսում ենք սկսել x86-64 ճարտարապետության, Linux-ի և ստատիկ կապի աջակցությամբ (դինամիկ բեռնում, կապակցում և լրացուցիչ ճարտարապետություններ կիրականացվեն երկրորդաբար):
Ծրագիրը դեռ մշակման սկզբնական փուլում է, սակայն հիմնական նպատակներն արդեն սահմանվել են.
- Մոդուլյարություն և զարգացում՝ ոչ թե մոնոլիտ հավաքածուի, այլ հատիկավոր գրադարան տրամադրելու փիլիսոփայության համաձայն.
- Աջակցություն ռեժիմներում ստատիկ կապակցման համար (Դիրքից անկախ գործադիրներ) և առանց PIE: Ստատիկ կապակցված գործադիրների համար CRT (C գործարկման ժամանակ) և PIE բեռնիչի ապահովում;
- Աջակցություն ստանդարտ C գրադարանի գործառույթների մեծ մասի համար՝ POSIX հավելումներով և գործող հավելվածների կողմից պահանջվող համակարգի հատուկ ընդլայնումներով.
- Զգույշ եղեք վաճառողի հատուկ ընդլայնումների հետ և ավելացրեք դրանք միայն անհրաժեշտության դեպքում: Ինչ վերաբերում է երրորդ կողմի ընդլայնումների աջակցությանը, ապա առաջարկվում է օգտագործել Clang և libc++ նախագծերի մոտեցումը.
- LLVM գործիքակազմի օգտագործմամբ մշակման մեջ լավագույն փորձի օգտագործումը, ինչպես օրինակ՝ ախտահանիչի և մռայլ փորձարկման օգտագործումը հենց սկզբից:
LLVM-ի ակտիվ մշակողներից մեկը Պարզ է, որ իմաստ ունի առաքել libc-ը որպես LLVM գործիքակազմի մաս, բայց սովորաբար, երբ նման անհրաժեշտություն է առաջանում, նրանք օգտագործում են musl գրադարանը, որը լավ գրված է, աջակցում է տարբեր ճարտարապետություններին և ապահովում է անհրաժեշտ ֆունկցիոնալությունը, ներառյալ դինամիկ աջակցությունը: կապող. Հնարավոր է, որ արդարացված լինի մուսուլը ներդնել LLVM-ում և զարգացնել այն որպես հիմնական նախագծի հետ համաժամանակացված պատառաքաղ:
Ձեր կարծիքը նույնպես Musl նախագծի հեղինակը, ով փորձել է վիճել, թե ինչու է Google-ի առաջարկը և Libc-ի ընդգրկումը LLVM բաշխման մեջ շատ վատ գաղափարներ.
- Ճիշտ, համատեղելի և բարձրորակ Libc-ի մշակումն ու պահպանումը շատ բարդ խնդիր է: Խնդիրը կոդի քանակի մեջ չէ, այլ ինտերֆեյսների իրականացման հարցում ճիշտ վարքագծի և դժվարությունների ապահովման մեջ է՝ հաշվի առնելով C/C++-ով երբևէ գրված հավելվածների հսկայական շերտը, ինչպես նաև այլ լեզուներով հավելվածները, որոնց գործարկման ժամանակը օգտագործվում է։ Libc-ի կողմից։ Առանց նրբերանգները հաշվի առնելու գլխավոր մոտեցումը միայն կհանգեցնի նրան, որ գոյություն ունեցող շատ ծրագրեր չեն կարողանա աշխատել Libc-ի հետ, բայց այդ դեպքում նման նախագիծը չի հետաքրքրի սպառողներին:
- Կորպորատիվ զարգացումը կարող է փչացնել Libc-ը, բայց մղել այն լայն կիրառման, ինչի հետևանքով անհրաժեշտ է հաքեր ավելացնել՝ հավելվածներում համատեղելիություն ապահովելու համար: Կորպորատիվ բաց կոդով նախագծի հովանու ներքո զարգացումը վերմակը կքաշի դեպի ընկերության կարիքներն ու լուծումները՝ ի վնաս համայնքի շահերի: Օրինակ, եթե դուք հայտնաբերում եք խնդիր, որն առաջացել է մեկ այլ ծրագրի սխալի պատճառով, վերահսկվող մշակման ժամանակ ավելի հեշտ է ապահովել, որ Libc-ը համատեղելի է այս վրիպակի հետ, քան ինքն իրեն ուղղել սխալը: Այս նպատակների համար Apple-ն օգտագործում է BSD libc պատառաքաղը, իսկ Google-ն օգտագործում է musl պատառաքաղը Fuchsia-ում: Մուսուլի մշակողի փորձն այն է, որ նրա հետ կապվել են հիմնականում իրավաբանները՝ լիցենզավորման հարցերը պարզաբանելու համար, բայց երբեք չեն դիմել՝ տեխնիկական մանրամասները ճշտելու համար՝ նախքան իր մասնաճյուղերում անօգուտ և խանգարող փոփոխություններ կատարելը:
- libc-ի մշակման մեջ մոնոմշակույթի բացակայությունը և կոնսենսուսի վրա հիմնված ստանդարտների վրա կենտրոնանալը, այլ ոչ թե անհատական վերահսկողությունը, ինչը դրդում է հավելվածների մշակողներին օգտագործել ստանդարտներ, այլ ոչ թե կապված լինել կոնկրետ իրականացումների հետ: Այդ իսկ պատճառով musl-ի հեղինակը դեմ է LLVM-ում իր գրադարանի ընդգրկմանը, ինչպես նաև LLVM-ում libc-ի զարգացմանը, քանի որ այս դեպքում կորչում է libc-ի անկախ բնույթը, և որոշակի իրականացումը դառնում է առաջին կարգի լուծում։ LLVM-ը և մնացած բոլորը դառնում են երկրորդ կարգի լուծում:
Source: opennet.ru