Google च्या विकसकांनी LLVM साठी त्यांचे स्वतःचे libc विकसित करण्याचे सुचवले

Google कडील विकसकांपैकी एक उठवले LLVM प्रोजेक्टचा भाग म्हणून मल्टी-प्लॅटफॉर्म स्टँडर्ड C लायब्ररी (Libc) च्या विकासाबद्दल LLVM मेलिंग लिस्टवर. अनेक कारणांमुळे, Google सध्याच्या libc (glibc, musl) बद्दल समाधानी नाही आणि कंपनी नवीन अंमलबजावणी विकसित करण्याच्या मार्गावर आहे, जी LLVM चा भाग म्हणून विकसित करण्याचा प्रस्ताव आहे.

LLVM विकास अलीकडे Google च्या असेंब्ली टूल्स तयार करण्यासाठी आधार म्हणून वापरला गेला आहे. मुख्य कल्पना अशी आहे की जर Google ने आधीच त्याचे libc विकसित करण्यास सुरुवात केली आहे, तर LLVM चा भाग म्हणून त्याची प्रणाली त्वरित विकसित का करू नये, जी आधीच C++ (Libc++) साठी स्वतःची मानक लायब्ररी ऑफर करते, परंतु C साठी समान मानक लायब्ररी नाही. (libc).

विकास टप्प्याटप्प्याने करण्याचे नियोजित आहे, हळूहळू कार्यक्षमता वाढवत आहे. पहिले पर्याय हे ऍप्लिकेशन आणि सिस्टीम Libc मधील एक थर म्हणून डिझाइन करण्याचे प्रस्तावित आहे, ज्यामधून अद्याप लागू न झालेली वैशिष्ट्ये उधार घेतली जातील. कार्यक्षमतेच्या एका विशिष्ट स्तरावर पोहोचल्यानंतर, नवीन Libc चा वापर Libc प्रणालीसाठी संपूर्ण बदली म्हणून केला जाऊ शकतो. आम्ही x86-64 आर्किटेक्चर, लिनक्स आणि स्टॅटिक लिंकिंग (डायनॅमिक लोडिंग, लिंकिंग आणि अतिरिक्त आर्किटेक्चर दुय्यमरित्या लागू केले जातील) साठी समर्थनासह प्रारंभ करण्याची योजना आखत आहोत.

प्रकल्प अद्याप विकासाच्या सुरुवातीच्या टप्प्यावर आहे, परंतु मूलभूत उद्दिष्टे आधीच परिभाषित केली गेली आहेत:

• मोनोलिथिक संचाऐवजी ग्रॅन्युलर लायब्ररी वितरीत करण्याच्या तत्त्वज्ञानानुसार मॉड्यूलरिटी आणि विकास;
• मोडमध्ये स्थिर लिंकिंगसाठी समर्थन पीआयई (पोझिशन-स्वतंत्र एक्झिक्युटेबल) आणि PIE शिवाय. स्टॅटिकली लिंक केलेल्या एक्झिक्यूटेबलसाठी सीआरटी (सी रनटाइम) आणि पीआयई लोडर प्रदान करणे;
• POSIX ऍडिशन्ससह आणि विद्यमान ऍप्लिकेशन्ससाठी आवश्यक असलेल्या काही सिस्टम-विशिष्ट विस्तारांसह बहुतेक मानक C लायब्ररी फंक्शन्ससाठी समर्थन;
• विक्रेता-विशिष्ट विस्तारांसह सावधगिरी बाळगा आणि आवश्यक असेल तेव्हाच ते जोडा. तृतीय-पक्ष विस्तारांसाठी समर्थनाबाबत, क्लँग आणि libc++ प्रकल्पांचा दृष्टिकोन वापरण्याचा प्रस्ताव आहे;
• LLVM टूलकिट वापरून विकासातील सर्वोत्तम पद्धती वापरणे, जसे की सॅनिटायझर वापरणे आणि अगदी सुरुवातीपासूनच फझ चाचणी करणे.

सक्रिय LLVM विकसकांपैकी एक निदर्शनास आणून दिलेहे स्पष्ट आहे की LLVM टूलकिटचा भाग म्हणून libc पाठवणे अर्थपूर्ण आहे, परंतु सामान्यतः, जेव्हा अशी गरज निर्माण होते, तेव्हा ते मसल लायब्ररीचा वापर करतात, जे चांगले लिहिलेले आहे, विविध आर्किटेक्चरला समर्थन देते आणि आवश्यक कार्यक्षमता प्रदान करते, ज्यामध्ये डायनॅमिकसाठी समर्थन समाविष्ट आहे. दुवा साधत आहे. LLVM मध्ये मस्ल एम्बेड करण्याचे आणि मुख्य प्रॉजेक्टशी समक्रमित काटा म्हणून विकसित करण्याचे समर्थन केले जाऊ शकते.

तुमचेही मत व्यक्त मुसल प्रकल्पाचे लेखक, ज्यांनी युक्तिवाद करण्याचा प्रयत्न केला की Google चा प्रस्ताव आणि LLVM वितरणामध्ये Libc चा समावेश का अतिशय वाईट कल्पना आहेत:

• योग्य, सुसंगत आणि उच्च-गुणवत्तेचे Libc विकसित करणे आणि राखणे हे खूप कठीण काम आहे. समस्या कोडच्या प्रमाणात नाही, परंतु योग्य वर्तन सुनिश्चित करण्यात आणि इंटरफेस लागू करण्यात येणाऱ्या अडचणी, C/C++ मध्ये लिहीलेल्या ऍप्लिकेशन्सचा मोठा स्तर, तसेच इतर भाषांमधील ऍप्लिकेशन्स लक्षात घेऊन, ज्याचा रनटाइम वापरला जातो. Libc द्वारे. बारकावे विचारात न घेता हेड-ऑन दृष्टीकोन केवळ या वस्तुस्थितीला कारणीभूत ठरेल की बरेच विद्यमान प्रोग्राम Libc सह कार्य करण्यास सक्षम होणार नाहीत, परंतु नंतर असा प्रकल्प ग्राहकांच्या हिताचा राहणार नाही.
• कॉर्पोरेट डेव्हलपमेंटमुळे Libc नष्ट होऊ शकते, परंतु त्याचा व्यापक वापर होऊ शकतो, परिणामी अनुप्रयोगांमध्ये सुसंगतता सुनिश्चित करण्यासाठी हॅक जोडण्याची आवश्यकता आहे. कॉर्पोरेट ओपन सोर्स प्रकल्पाच्या आश्रयाने होणारा विकास, कंपनीच्या गरजा आणि उपायांसाठी, समुदायाच्या हितसंबंधांना हानी पोहोचवेल. उदाहरणार्थ, जर तुम्ही दुसऱ्या प्रोग्राममधील बगमुळे उद्भवलेली समस्या ओळखली तर, नियंत्रित विकासामध्ये Libc या बगशी सुसंगत असल्याची खात्री करणे हे बग स्वतःच निराकरण करण्यापेक्षा सोपे आहे. Apple या उद्देशांसाठी BSD libc काटा वापरते आणि Google Fuchsia मध्ये musl fork वापरते. मुसल डेव्हलपरचा अनुभव असा आहे की त्याच्याशी मुख्यत्वे वकिलांनी परवाना समस्या स्पष्ट करण्यासाठी संपर्क साधला होता, परंतु त्याच्या शाखांमध्ये निरुपयोगी आणि व्यत्यय आणणारे बदल करण्यापूर्वी तांत्रिक तपशील स्पष्ट करण्यासाठी कधीही संपर्क साधला गेला नाही.
• libc विकासामध्ये मोनोकल्चरची अनुपस्थिती आणि वैयक्तिक नियंत्रणाऐवजी एकमत-चालित मानकांवर लक्ष केंद्रित करणे, जे अनुप्रयोग विकासकांना विशिष्ट अंमलबजावणीशी जोडण्याऐवजी मानकांचा वापर करण्यास प्रवृत्त करते. म्हणूनच मुसलचा लेखक LLVM मध्ये त्याच्या लायब्ररीचा समावेश करण्याच्या विरोधात आहे, तसेच LLVM मध्ये libc च्या विकासाच्या विरोधात आहे, कारण या प्रकरणात libc चे स्वतंत्र स्वरूप नष्ट होते आणि एक विशिष्ट अंमलबजावणी हा प्रथम श्रेणीचा उपाय बनतो. LLVM आणि इतर सर्व द्वितीय श्रेणीचे समाधान बनतात.

स्त्रोत: opennet.ru