د ګوګل څخه یو له پراختیا کونکو څخه د LLVM پروژې د یوې برخې په توګه د څو پلیټ فارم معیاري C کتابتون (Libc) پراختیا په اړه د LLVM بریښنالیک لیست کې. د یو شمیر دلایلو لپاره، ګوګل د اوسني libc (glibc، musl) څخه راضي نه دی او شرکت د نوي پلي کولو په لاره کې دی، کوم چې وړاندیز شوی چې د LLVM برخې په توګه پراختیا ومومي.
د LLVM پرمختګونه پدې وروستیو کې د ګوګل د مجلس وسیلو جوړولو لپاره د اساس په توګه کارول شوي. اصلي نظر دا دی چې که ګوګل دمخه د خپل libc پراختیا پیل کړې وي ، نو ولې سمدلاسه د LLVM برخې په توګه خپل سیسټم نه رامینځته کوي ، کوم چې دمخه د C++ (Libc++) لپاره خپل معیاري کتابتون وړاندې کوي ، مګر د C لپاره ورته معیاري کتابتون نلري. (libc).
پراختیا پالن شوی چې په مرحلو کې ترسره شي، په تدریجي ډول د فعالیت زیاتوالی. لومړي اختیارونه وړاندیز شوي چې د غوښتنلیک او سیسټم Libc تر مینځ د پرت په توګه ډیزاین شي ، له کوم څخه هغه ځانګړتیاوې چې تراوسه ندي پلي شوي پور اخیستل کیږي. د فعالیت یوې ټاکلې کچې ته رسیدو وروسته ، نوی Libc د Libc سیسټم لپاره د بشپړ بدیل په توګه کارول کیدی شي. موږ پلان لرو چې د x86-64 معمارۍ ، لینکس ، او جامد لینک کولو ملاتړ سره پیل وکړو (متحرک بار کول ، لینک کول ، او اضافي جوړښتونه به په دوهم ډول پلي شي).
پروژه لا تر اوسه د پراختیا په لومړي پړاو کې ده، مګر بنسټیز اهداف لا دمخه تعریف شوي دي:
- ماډلریت او پراختیا د فلسفې سره سم د یو واحد سیټ پرځای د ګران کتابتون وړاندې کول؛
- په حالتونو کې د جامد لینک کولو لپاره ملاتړ (د موقعیت خپلواک اجرایوي) او د PIE پرته. د سی آر ټي (C رن ټایم) او PIE لوډر چمتو کول د ثابت سره تړل شوي اجرایوي لپاره؛
- د ډیری معیاري C کتابتون دندو لپاره ملاتړ، د POSIX اضافې سره او د موجوده غوښتنلیکونو لخوا اړین ځینې سیسټم ځانګړي توسیعونه؛
- د پلورونکي ځانګړي توسیعونو سره محتاط اوسئ او یوازې د اړتیا په وخت کې یې اضافه کړئ. د دریمې ډلې غزولو لپاره د ملاتړ په اړه، دا وړاندیز کیږي چې د کلینګ او libc++ پروژو طریقه وکاروي؛
- د LLVM اوزار کټ په کارولو سره په پراختیا کې د غوره تمرینونو کارول ، لکه له پیل څخه د سینیټیزر او فز ټیسټ کارول.
یو له فعال LLVM پراختیا کونکو څخه دا روښانه ده چې د LLVM اوزار کټ یوې برخې په توګه د libc لیږل معنی لري ، مګر معمولا ، کله چې ورته اړتیا رامینځته شي ، دوی د مسل کتابتون کاروي ، کوم چې ښه لیکل شوی ، د مختلف جوړښتونو ملاتړ کوي ، او اړین فعالیت چمتو کوي ، پشمول د متحرک لپاره ملاتړ. نښلول دا ممکن د توجیه وړ وي چې مسل په LLVM کې ځای په ځای کړي او د اصلي پروژې سره همغږي شوي فورک په توګه رامینځته کړي.
ستاسو نظر هم د مسل پروژې لیکوال، چې هڅه یې کوله استدلال وکړي چې ولې د ګوګل وړاندیز او د LLVM ویش کې د Libc شاملول خورا بد نظرونه دي:
- د یو درست، مطابقت لرونکي، او لوړ کیفیت لرونکي Libc پراختیا او ساتل خورا ستونزمن کار دی. ستونزه د کوډ په مقدار کې نده ، مګر د سم چلند او د انٹرفیس پلي کولو کې ستونزې ډاډمن کولو کې ، د غوښتنلیکونو لوی پرت په پام کې نیولو سره چې تل په C/C++ کې لیکل شوي ، او همدارنګه په نورو ژبو کې غوښتنلیکونه ، چې د چلولو وخت کارول کیږي. د Libc لخوا. د باریکیو په پام کې نیولو پرته د سر سره چلند به یوازې د دې حقیقت لامل شي چې ډیری موجوده برنامې به د Libc سره کار کولو توان ونلري ، مګر بیا دا ډول پروژه به د مصرف کونکو لپاره علاقه ونلري.
- د کارپوریټ پراختیا کولی شي Libc خراب کړي، مګر دا د پراخې کارونې لپاره فشار راوړي، په پایله کې د غوښتنلیکونو مطابقت ډاډمن کولو لپاره د هیکونو اضافه کولو اړتیا. د کارپوریټ د خلاصې سرچینې پروژې تر نظارت لاندې پراختیا به د شرکت اړتیاو او حلونو ته کمبل راوباسي چې د ټولنې ګټو ته زیان ورسوي. د مثال په توګه، که تاسو یوه ستونزه پیژنئ چې په بل برنامه کې د بګ له امله رامینځته کیږي ، په کنټرول شوي پراختیا کې دا ډاډ ترلاسه کول اسانه دي چې Libc پخپله د بګ حل کولو په پرتله د دې بګ سره مطابقت لري. ایپل د دې موخو لپاره د BSD libc فورک کاروي، او ګوګل په Fuchsia کې د مسل فورک کاروي. د مسل د پراختیا کونکي تجربه دا ده چې هغه په عمده توګه د وکیلانو لخوا د جواز ورکولو مسلو روښانه کولو لپاره اړیکه نیول شوې وه، مګر هیڅکله یې د هغه په څانګو کې بې ګټې او ګډوډي بدلونونو کولو دمخه د تخنیکي توضیحاتو روښانه کولو لپاره اړیکه نه وه نیولې.
- د libc پراختیا کې د مونوکلچر نشتوالی او د انفرادي کنټرول پرځای د توافق پر اساس معیارونو باندې تمرکز ، کوم چې د غوښتنلیک پراختیا کونکي هڅوي چې معیارونه وکاروي پرځای یې د ځانګړي پلي کولو پورې تړلي وي. له همدې امله د مسل لیکوال په LLVM کې د خپل کتابتون د شاملولو مخالف دی ، او همدارنګه په LLVM کې د libc د پراختیا مخالف دی ، ځکه چې پدې حالت کې د libc خپلواکه ماهیت له لاسه ورکوي او یو مشخص پلي کول د لومړي درجې حل کیږي. LLVM، او نور ټول د دویمې درجې حل کیږي.
سرچینه: opennet.ru