អ្នកអភិវឌ្ឍន៍ពី 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 លីនុច និងការភ្ជាប់ឋិតិវន្ត (ការផ្ទុកថាមវន្ត ការភ្ជាប់ និងស្ថាបត្យកម្មបន្ថែមនឹងត្រូវបានអនុវត្តជាបន្ទាប់បន្សំ)។

គម្រោងនេះនៅតែស្ថិតក្នុងដំណាក់កាលដំបូងនៃការអភិវឌ្ឍន៍ ប៉ុន្តែគោលដៅជាមូលដ្ឋានត្រូវបានកំណត់រួចហើយ៖

• ម៉ូឌុលនិងការអភិវឌ្ឍន៍ស្របតាមទស្សនវិជ្ជានៃការផ្តល់បណ្ណាល័យជាក្រឡាជាជាងសំណុំ monolithic;
• ការគាំទ្រសម្រាប់ការភ្ជាប់ឋិតិវន្តនៅក្នុងរបៀប PIE (Position-independent executables) និងដោយគ្មាន PIE ។ ការផ្តល់ CRT (C runtime) និង PIE loader សម្រាប់ការប្រតិបត្តិដែលភ្ជាប់គ្នាដោយឋិតិវន្ត។
• ការគាំទ្រសម្រាប់មុខងារបណ្ណាល័យ C ស្តង់ដារភាគច្រើន ជាមួយនឹងការបន្ថែម POSIX និងផ្នែកបន្ថែមជាក់លាក់នៃប្រព័ន្ធមួយចំនួនដែលត្រូវការដោយកម្មវិធីដែលមានស្រាប់។
• សូមប្រយ័ត្នជាមួយផ្នែកបន្ថែមជាក់លាក់របស់អ្នកលក់ ហើយបន្ថែមវានៅពេលចាំបាច់ប៉ុណ្ណោះ។ ទាក់ទងនឹងការគាំទ្រសម្រាប់ផ្នែកបន្ថែមភាគីទីបី វាត្រូវបានស្នើឱ្យប្រើវិធីសាស្រ្តនៃគម្រោង Clang និង libc++ ។
• ការប្រើប្រាស់ការអនុវត្តល្អបំផុតក្នុងការអភិវឌ្ឍន៍ដោយប្រើប្រអប់ឧបករណ៍ LLVM ដូចជាការប្រើទឹកអនាម័យ និងការធ្វើតេស្ត fuzz តាំងពីដំបូង។

មួយក្នុងចំណោមអ្នកអភិវឌ្ឍន៍ LLVM សកម្ម ចង្អុលបង្ហាញវាច្បាស់ណាស់ថាវាសមហេតុផលក្នុងការបញ្ជូន libc ជាផ្នែកមួយនៃកញ្ចប់ឧបករណ៍ LLVM ប៉ុន្តែជាធម្មតានៅពេលដែលមានតម្រូវការបែបនេះ ពួកគេប្រើប្រាស់បណ្ណាល័យ musl ដែលបានសរសេរយ៉ាងល្អ គាំទ្រស្ថាបត្យកម្មផ្សេងៗ និងផ្តល់នូវមុខងារចាំបាច់ រួមទាំងការគាំទ្រសម្រាប់ថាមវន្ត។ ការភ្ជាប់។ វាប្រហែលជាត្រឹមត្រូវក្នុងការបញ្ចូល musl ទៅក្នុង LLVM ហើយអភិវឌ្ឍវាជាសមដែលធ្វើសមកាលកម្មជាមួយគម្រោងមេ។

យោបល់របស់អ្នកផងដែរ។ បានសម្តែង អ្នកនិពន្ធនៃគម្រោង Musl ដែលបានព្យាយាមប្រកែកថាហេតុអ្វីបានជាសំណើរបស់ Google និងការដាក់បញ្ចូល Libc ក្នុងការចែកចាយ LLVM គឺជាគំនិតអាក្រក់ខ្លាំងណាស់៖

• ការអភិវឌ្ឍន៍ និងថែរក្សា Libc ត្រឹមត្រូវ ឆបគ្នា និងគុណភាពខ្ពស់ គឺជាកិច្ចការដ៏លំបាកមួយ។ បញ្ហាមិនស្ថិតនៅលើចំនួនកូដនោះទេ ប៉ុន្តែក្នុងការធានានូវឥរិយាបថត្រឹមត្រូវ និងការលំបាកក្នុងការអនុវត្តចំណុចប្រទាក់ ដោយគិតគូរពីស្រទាប់ដ៏ធំនៃកម្មវិធីដែលធ្លាប់សរសេរក្នុង C/C++ ក៏ដូចជាកម្មវិធីជាភាសាផ្សេងទៀត ពេលវេលាដំណើរការដែលត្រូវបានប្រើ។ ដោយ Libc ។ វិធីសាស្រ្តនាំមុខដោយមិនគិតពីការ nuances នឹងនាំឱ្យការពិតដែលថាកម្មវិធីដែលមានស្រាប់ជាច្រើននឹងមិនអាចធ្វើការជាមួយ Libc បានទេ ប៉ុន្តែបន្ទាប់មកគម្រោងបែបនេះនឹងមិនមានការចាប់អារម្មណ៍ចំពោះអ្នកប្រើប្រាស់នោះទេ។
• ការអភិវឌ្ឍន៍សាជីវកម្មអាចបំផ្លាញ Libc ប៉ុន្តែជំរុញឱ្យវាប្រើប្រាស់យ៉ាងទូលំទូលាយ ដែលបណ្តាលឱ្យមានតម្រូវការបន្ថែមការលួចចូល ដើម្បីធានាភាពឆបគ្នានៅក្នុងកម្មវិធី។ ការអភិវឌ្ឍន៍ក្រោមការឧបត្ថម្ភនៃគម្រោងប្រភពបើកចំហរបស់សាជីវកម្មនឹងទាញភួយឆ្ពោះទៅរកតម្រូវការ និងដំណោះស្រាយរបស់ក្រុមហ៊ុន ដល់ការបំផ្លាញផលប្រយោជន៍របស់សហគមន៍។ ឧទាហរណ៍ ប្រសិនបើអ្នកកំណត់បញ្ហាដែលបណ្តាលមកពីកំហុសនៅក្នុងកម្មវិធីផ្សេងទៀត ក្នុងការអភិវឌ្ឍន៍ដែលបានគ្រប់គ្រង វាកាន់តែងាយស្រួលក្នុងការធានាថា Libc អាចត្រូវគ្នាជាមួយនឹងកំហុសនេះ ជាជាងជួសជុលកំហុសខ្លួនឯង។ Apple ប្រើ BSD libc fork សម្រាប់គោលបំណងទាំងនេះ ហើយ Google ប្រើ musl fork នៅក្នុង Fuchsia ។ បទពិសោធន៍របស់អ្នកអភិវឌ្ឍន៍ musl គឺថាគាត់ត្រូវបានទាក់ទងជាចម្បងដោយមេធាវីដើម្បីបញ្ជាក់ពីបញ្ហាអាជ្ញាប័ណ្ណ ប៉ុន្តែមិនត្រូវបានទាក់ទងដើម្បីបញ្ជាក់ពីព័ត៌មានលម្អិតបច្ចេកទេសមុនពេលធ្វើការផ្លាស់ប្តូរដែលគ្មានប្រយោជន៍ និងរំខានដល់សាខារបស់គាត់។
• អវត្ដមាននៃវប្បធម៌ឯកត្តជនក្នុងការអភិវឌ្ឍន៍ libc និងការផ្តោតលើស្តង់ដារដែលជំរុញដោយមតិជាជាងការគ្រប់គ្រងបុគ្គល ដែលជំរុញឱ្យអ្នកបង្កើតកម្មវិធីប្រើប្រាស់ស្តង់ដារជាជាងត្រូវបានចងភ្ជាប់ទៅនឹងការអនុវត្តជាក់លាក់។ នោះហើយជាមូលហេតុដែលអ្នកនិពន្ធនៃ musl ប្រឆាំងនឹងការដាក់បញ្ចូលបណ្ណាល័យរបស់គាត់នៅក្នុង LLVM ក៏ដូចជាប្រឆាំងនឹងការអភិវឌ្ឍនៃ libc នៅក្នុង LLVM ចាប់តាំងពីក្នុងករណីនេះ លក្ខណៈឯករាជ្យនៃ libc ត្រូវបានបាត់បង់ ហើយការអនុវត្តជាក់លាក់មួយក្លាយជាដំណោះស្រាយថ្នាក់ដំបូងសម្រាប់ LLVM និងអ្នកផ្សេងទៀតទាំងអស់ក្លាយជាដំណោះស្រាយលំដាប់ទីពីរ។

ប្រភព: opennet.ru