Google-ის დეველოპერებმა შესთავაზეს საკუთარი libc-ის შემუშავება LLVM-ისთვის

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 (პოზიციიდან დამოუკიდებელი შესრულებადი ფაილები) და PIE-ის გარეშე. CRT (C runtime) და PIE loader-ის უზრუნველყოფა სტატიკურად დაკავშირებული შესრულებადებისთვის;
• C ბიბლიოთეკის სტანდარტული ფუნქციების უმეტესობის მხარდაჭერა, POSIX დამატებებით და არსებული აპლიკაციებისთვის საჭირო სისტემის სპეციფიკური გაფართოებებით;
• ფრთხილად იყავით გამყიდველის სპეციფიკურ გაფართოებებთან და დაამატეთ ისინი მხოლოდ საჭიროების შემთხვევაში. რაც შეეხება მესამე მხარის გაფართოებების მხარდაჭერას, შემოთავაზებულია გამოიყენოს Clang და libc++ პროექტების მიდგომა;
• განვითარებაში საუკეთესო პრაქტიკის გამოყენება LLVM ინსტრუმენტარიუმის გამოყენებით, როგორიცაა დეზინფექციის და ფუზ ტესტირების გამოყენება თავიდანვე.

LLVM-ის ერთ-ერთი აქტიური დეველოპერი აღნიშნაგასაგებია, რომ აზრი აქვს libc-ის გაგზავნას LLVM ინსტრუმენტარიუმის ნაწილად, მაგრამ ჩვეულებრივ, როდესაც ასეთი საჭიროება ჩნდება, ისინი იყენებენ musl ბიბლიოთეკას, რომელიც კარგად არის დაწერილი, მხარს უჭერს სხვადასხვა არქიტექტურას და უზრუნველყოფს აუცილებელ ფუნქციებს, მათ შორის დინამიური მხარდაჭერას. აკავშირებს. შეიძლება გამართლებული იყოს musl-ის ჩასმა LLVM-ში და მისი განვითარება მთავარ პროექტთან სინქრონიზებული ჩანგლის სახით.

თქვენი აზრიც გამოხატული Musl პროექტის ავტორი, რომელიც ცდილობდა დაემტკიცებინა, რატომ არის Google-ის წინადადება და LLVM დისტრიბუციაში Libc-ის ჩართვა ძალიან ცუდი იდეები:

• სწორი, თავსებადი და მაღალი ხარისხის Libc-ის შემუშავება და შენარჩუნება ძალიან რთული ამოცანაა. პრობლემა არის არა კოდის რაოდენობაში, არამედ სწორი ქცევის უზრუნველყოფაში და ინტერფეისების დანერგვის სირთულეებში, C/C++-ში დაწერილი აპლიკაციების უზარმაზარი ფენის გათვალისწინებით, ისევე როგორც სხვა ენების აპლიკაციები, რომელთა გაშვების დროც გამოიყენება. Libc-ის მიერ. წინასწარი მიდგომა ნიუანსების გათვალისწინების გარეშე მხოლოდ გამოიწვევს იმ ფაქტს, რომ ბევრი არსებული პროგრამა ვერ შეძლებს Libc-თან მუშაობას, მაგრამ შემდეგ ასეთი პროექტი არ იქნება დაინტერესებული მომხმარებლებისთვის.
• კორპორატიულმა განვითარებამ შეიძლება გაანადგუროს Libc, მაგრამ უბიძგოს მას ფართო გამოყენებისთვის, რის შედეგადაც საჭიროა ჰაკების დამატება აპლიკაციებში თავსებადობის უზრუნველსაყოფად. კორპორატიული ღია კოდის პროექტის ეგიდით განვითარება საბანს გაიყვანს კომპანიის საჭიროებებისა და გადაწყვეტილებებისკენ, საზოგადოების ინტერესების საზიანოდ. მაგალითად, თუ თქვენ იდენტიფიცირებთ პრობლემას, რომელიც გამოწვეულია სხვა პროგრამის შეცდომით, კონტროლირებადი განვითარებისას უფრო ადვილია უზრუნველყოთ, რომ Libc თავსებადია ამ შეცდომასთან, ვიდრე თავად შეცდომის გამოსწორება. Apple ამ მიზნებისთვის იყენებს BSD libc ჩანგალს, ხოლო Google იყენებს musl fork-ს ფუქსიაში. musl-ის შემქმნელის გამოცდილება არის ის, რომ მას ძირითადად იურისტები დაუკავშირდნენ ლიცენზირების საკითხების გასარკვევად, მაგრამ არასოდეს დაუკავშირდნენ ტექნიკური დეტალების გასარკვევად, სანამ მის ფილიალებში უსარგებლო და დამაბრკოლებელ ცვლილებებს შეიტანდნენ.
• libc განვითარებაში მონოკულტურის არარსებობა და კონსენსუსზე ორიენტირებულ სტანდარტებზე ფოკუსირება და არა ინდივიდუალურ კონტროლზე, რაც აპლიკაციის შემქმნელებს უბიძგებს გამოიყენონ სტანდარტები, ვიდრე მიბმული იყვნენ კონკრეტულ განხორციელებასთან. სწორედ ამიტომ musl-ის ავტორი წინააღმდეგია მისი ბიბლიოთეკის LLVM-ში ჩართვის, ასევე LLVM-ში libc-ის განვითარების წინააღმდეგი, რადგან ამ შემთხვევაში libc-ის დამოუკიდებელი ბუნება იკარგება და გარკვეული განხორციელება ხდება პირველი კლასის გადაწყვეტა. LLVM და ყველა სხვა ხდება მეორე კლასის გადაწყვეტა.

წყარო: opennet.ru