Google မှ developer များက LLVM အတွက် ၎င်းတို့၏ ကိုယ်ပိုင် libc ကို တီထွင်ရန် အကြံပြုခဲ့သည်။

Google မှ developer တစ်ဦးဖြစ်သည်။ ထမြောက်သည်။ LLVM ပရောဂျက်၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့် multi-platform standard C library (Libc) ဖွံ့ဖြိုးတိုးတက်မှုအကြောင်း LLVM mailing list တွင်။ အကြောင်းအမျိုးမျိုးကြောင့်၊ Google သည် လက်ရှိ libc (glibc၊ musl) ကို မကျေနပ်သဖြင့် ကုမ္ပဏီသည် LLVM ၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် တီထွင်ထုတ်လုပ်ရန် အဆိုပြုထားသည့် အကောင်အထည်ဖော်မှုအသစ်တစ်ခုကို ဖော်ဆောင်ရန် လမ်းကြောင်းပေါ်ရောက်နေပါသည်။

LLVM ဖွံ့ဖြိုးတိုးတက်မှုများကို မကြာသေးမီက Google ၏ တပ်ဆင်ရေးကိရိယာများ တည်ဆောက်ရန်အတွက် အခြေခံအဖြစ် အသုံးပြုခဲ့သည်။ အဓိက အယူအဆမှာ Google သည် ၎င်း၏ libc ကို စတင်ရေးဆွဲနေပြီဆိုလျှင်၊ C++ (Libc++) အတွက် ၎င်း၏ကိုယ်ပိုင်စံပြစာကြည့်တိုက်ကို ပေးဆောင်ထားပြီးဖြစ်သည့် LLVM ၏ အစိတ်အပိုင်းတစ်ခုအနေဖြင့် ၎င်းစနစ်အား ချက်ချင်းမဖန်တီးဘဲ C++ အတွက် အလားတူ စံစာကြည့်တိုက်တစ်ခု မရှိပါ။ (libc)။

ဖွံ့ဖြိုးတိုးတက်ရေးကို အဆင့်ဆင့်လုပ်ဆောင်ရန် စီစဉ်ထားပြီး လုပ်ဆောင်နိုင်စွမ်းများကို တဖြည်းဖြည်း တိုးမြှင့်လုပ်ဆောင်သွားမည်ဖြစ်သည်။ ပထမရွေးချယ်စရာများကို အပလီကေးရှင်းနှင့် စနစ် Libc အကြား အလွှာတစ်ခုအဖြစ် ဒီဇိုင်းရေးဆွဲရန် အဆိုပြုထားပြီး၊ အကောင်အထည်မဖော်ရသေးသည့် အင်္ဂါရပ်များကို ချေးယူမည်ဖြစ်သည်။ လုပ်ဆောင်ချက်အချို့အဆင့်သို့ရောက်ရှိပြီးနောက်၊ Libc အသစ်ကို စနစ် Libc အတွက် ပြီးပြည့်စုံသော အစားထိုးမှုအဖြစ် အသုံးပြုနိုင်ပါသည်။ ကျွန်ုပ်တို့သည် x86-64 ဗိသုကာပညာ၊ Linux၊ နှင့် static linking အတွက် ပံ့ပိုးမှုဖြင့် စတင်ရန် စီစဉ်ထားသည် (dynamic loading၊ linking နှင့် အပိုဗိသုကာများကို ဒုတိယအားဖြင့် အကောင်အထည်ဖေါ်မည်)။

ပရောဂျက်သည် ဖွံ့ဖြိုးတိုးတက်မှု၏ ကနဦးအဆင့်တွင် ရှိနေဆဲဖြစ်သော်လည်း အခြေခံပန်းတိုင်များကို သတ်မှတ်ပြီးဖြစ်သည်-

• monolithic set မဟုတ်ဘဲ granular စာကြည့်တိုက်ကို ပေးအပ်ခြင်း၏ ဒဿနနှင့်အညီ ရွေ့လျားမှုနှင့် ဖွံ့ဖြိုးတိုးတက်မှု၊
• မုဒ်များတွင် တည်ငြိမ်သောလင့်ခ်ချိတ်ခြင်းအတွက် ပံ့ပိုးမှု ပိုင် (Position-independent executables) နှင့် PIE မပါဘဲ။ တည်ငြိမ်စွာချိတ်ဆက်ထားသော စီစဥ်လုပ်ဆောင်နိုင်သည့်အရာများအတွက် CRT (C runtime) နှင့် PIE loader ကို ပံ့ပိုးပေးခြင်း၊
• POSIX ပေါင်းထည့်မှုများနှင့် ရှိပြီးသား အပလီကေးရှင်းများမှ လိုအပ်သော စနစ်အလိုက် တိုးချဲ့မှုအချို့နှင့်အတူ စံ C စာကြည့်တိုက်လုပ်ဆောင်ချက်အများစုအတွက် ပံ့ပိုးမှု။
• ရောင်းချသူ-သီးသန့် တိုးချဲ့မှုများကို သတိထားပါ၊ လိုအပ်သည့်အခါမှသာ ထည့်သွင်းပါ။ Third-party extensions များအတွက် ပံ့ပိုးမှုနှင့်ပတ်သက်၍၊ Clang နှင့် libc++ ပရောဂျက်များ၏ ချဉ်းကပ်မှုကို အသုံးပြုရန် အဆိုပြုထားသည်။
• အစကတည်းက လက်ဆေးရည်နှင့် fuzz စမ်းသပ်ခြင်းကဲ့သို့သော LLVM ကိရိယာအစုံကို အသုံးပြု၍ ဖွံ့ဖြိုးတိုးတက်မှုတွင် အကောင်းဆုံးအလေ့အကျင့်များကို အသုံးပြုခြင်း။

တက်ကြွသော LLVM developer များထဲမှတစ်ဦး ထောက်ပြသည်LLVM toolkit ၏တစ်စိတ်တစ်ပိုင်းအနေဖြင့် libc ကို ပို့ဆောင်ခြင်းသည် အဓိပ္ပာယ်ရှိပါသည်၊ သို့သော် ပုံမှန်အားဖြင့်၊ ထိုသို့လိုအပ်သည့်အခါတွင် ကောင်းမွန်စွာရေးသားထားသော၊ အမျိုးမျိုးသော ဗိသုကာလက်ရာများကို ပံ့ပိုးပေးသည့် musl စာကြည့်တိုက်ကို အသုံးပြုကြပြီး လိုအပ်သောလုပ်ဆောင်နိုင်စွမ်းများကို ပံ့ပိုးပေးပါသည်။ ချိတ်ဆက်ခြင်း။ musl ကို LLVM တွင် မြှုပ်နှံပြီး ပင်မပရောဂျက်နှင့် ထပ်တူပြုသော ခက်ရင်းတစ်ခုအဖြစ် ဖော်ဆောင်ရန် မျှတနိုင်သည်။

မင်းရဲ့ထင်မြင်ချက်လည်း ဖော်ပြခဲ့သည်။ Google ၏ အဆိုပြုချက်နှင့် Libc ကို LLVM ဖြန့်ဖြူးမှုတွင် အဘယ်ကြောင့် ထည့်သွင်းထားသည်ကို ငြင်းခုံရန်ကြိုးစားသော Musl ပရောဂျက်ကို ရေးသားသူသည် အလွန်ဆိုးရွားသော အတွေးအခေါ်များဖြစ်သည်-

• မှန်ကန်သော၊ လိုက်ဖက်ညီပြီး အရည်အသွေးမြင့် Libc ကို တည်ဆောက်ထိန်းသိမ်းခြင်းသည် အလွန်ခက်ခဲသောအလုပ်ဖြစ်သည်။ ပြဿနာသည် ကုဒ်ပမာဏတွင်မဟုတ်သော်လည်း၊ မှန်ကန်သောအပြုအမူနှင့် အင်တာဖေ့စ်များကို အကောင်အထည်ဖော်ရာတွင် အခက်အခဲများကို သေချာစေရန်အတွက်၊ C/C++ တွင် ရေးသားခဲ့ဖူးသည့် အသုံးချပရိုဂရမ်များအပြင် အခြားဘာသာစကားဖြင့် အက်ပ်ပလီကေးရှင်းများ၊ အသုံးပြုသည့် runtime၊ Libc မှ ရှိပြီးသားပရိုဂရမ်များစွာသည် Libc နှင့်အလုပ်လုပ်နိုင်မည်မဟုတ်ဟူသောအချက်ကိုသာထည့်သွင်းစဉ်းစားခြင်းဖြင့်သာထိုပရောဂျက်သည်စားသုံးသူများအတွက်စိတ်ဝင်စားလိမ့်မည်မဟုတ်ပေ။
• ကော်ပိုရိတ်ဖွံ့ဖြိုးတိုးတက်မှုသည် Libc ကို ပျက်စီးစေနိုင်သော်လည်း ၎င်းကို ကျယ်ကျယ်ပြန့်ပြန့်အသုံးပြုရန်အတွက် တွန်းအားပေးခြင်းဖြင့် အက်ပ်လီကေးရှင်းများတွင် လိုက်ဖက်မှုရှိစေရန် ဟက်ခ်များကို ထည့်သွင်းရန်လိုအပ်သည်။ ကော်ပိုရိတ် open source ပရောဂျက်တစ်ခု၏ ပံ့ပိုးကူညီမှုအောက်တွင် ဖွံ့ဖြိုးတိုးတက်မှုသည် ကုမ္ပဏီ၏ လိုအပ်ချက်များနှင့် ဖြေရှင်းချက်များဆီသို့ စောင်ကို ဆွဲတင်မည်ဖြစ်ပြီး ရပ်ရွာ၏ အကျိုးစီးပွားကို ထိခိုက်စေပါသည်။ ဥပမာအားဖြင့်၊ သင်သည် အခြားပရိုဂရမ်တစ်ခုရှိ bug တစ်ခုကြောင့်ဖြစ်ရသည့် ပြဿနာကို ရှာဖွေဖော်ထုတ်ပါက၊ ထိန်းချုပ်ထားသော ဖွံ့ဖြိုးတိုးတက်မှုတွင် Libc သည် bug ကို ကိုယ်တိုင်ပြုပြင်ခြင်းထက် ဤ bug နှင့် သဟဇာတဖြစ်ကြောင်း သေချာစေရန် ပိုမိုလွယ်ကူသည်။ Apple သည် ဤရည်ရွယ်ချက်များအတွက် BSD libc fork ကိုအသုံးပြုပြီး Google သည် Fuchsia တွင် musl ခက်ရင်းကိုအသုံးပြုသည်။ Musl developer ၏ အတွေ့အကြုံမှာ လိုင်စင်ပြဿနာများကို ရှင်းလင်းရန် ရှေ့နေများမှ အဓိကအားဖြင့် ဆက်သွယ်ခဲ့သော်လည်း ၎င်း၏အကိုင်းအခက်များကို အသုံးမဝင်၍ အနှောက်အယှက်ဖြစ်စေသော အပြောင်းအလဲများမပြုလုပ်မီ နည်းပညာဆိုင်ရာအသေးစိတ်အချက်အလက်များကို ရှင်းလင်းပေးရန် အဆက်အသွယ်မရရှိခဲ့ပါ။
• libc ဖွံ့ဖြိုးတိုးတက်မှုတွင် monoculture မရှိခြင်းနှင့် တစ်ဦးချင်းထိန်းချုပ်ခြင်းထက် အများဆန္ဒဖြင့်မောင်းနှင်သော စံချိန်စံညွှန်းများအပေါ် အာရုံစိုက်ခြင်းဖြစ်ပြီး၊ တိကျသောအကောင်အထည်ဖော်မှုများနှင့်ချိတ်ဆက်မည့်အစား အပလီကေးရှင်းဆော့ဖ်ဝဲရေးသားသူများအား စံနှုန်းများကိုအသုံးပြုရန် လှုံ့ဆော်ပေးပါသည်။ ထို့ကြောင့် musl ၏စာရေးသူသည် LLVM တွင်သူ၏စာကြည့်တိုက်ကိုထည့်သွင်းခြင်းအပြင် LLVM အတွင်းရှိ libc ၏ဖွံ့ဖြိုးတိုးတက်မှုကိုဆန့်ကျင်သည်ဖြစ်သောကြောင့်၊ ဤအခြေအနေတွင် libc ၏လွတ်လပ်သောသဘောသဘာဝသည်ပျောက်ဆုံးသွားပြီးအချို့သောအကောင်အထည်ဖော်မှုများအတွက်ပထမတန်းစားဖြေရှင်းချက်ဖြစ်လာသည်။ LLVM နှင့် အခြားအရာအားလုံးသည် ဒုတိယတန်းစားဖြေရှင်းချက်ဖြစ်လာသည်။

source: opennet.ru