Google වෙතින් සංවර්ධකයන්ගෙන් එක් අයෙකි
Google හි එකලස් කිරීමේ මෙවලම් තැනීමේ පදනම ලෙස LLVM වර්ධනයන් මෑතකදී භාවිතා කර ඇත. ප්රධාන අදහස නම්, Google දැනටමත් එහි libc සංවර්ධනය කිරීමට පටන් ගෙන තිබේ නම්, C++ (Libc++) සඳහා දැනටමත් තමන්ගේම සම්මත පුස්තකාලයක් ලබා දෙන LLVM හි කොටසක් ලෙස එහි පද්ධතිය වහාම සංවර්ධනය නොකරන්නේ මන්ද යන්නයි, නමුත් C සඳහා සමාන සම්මත පුස්තකාලයක් නොමැත. (libc).
සංවර්ධනය ක්රමයෙන් ක්රියාකාරීත්වය වැඩි කරමින් අදියර වශයෙන් සිදු කිරීමට සැලසුම් කර ඇත. පළමු විකල්පයන් යෙදුම සහ Libc පද්ධතිය අතර ස්ථරයක් ලෙස සැලසුම් කිරීමට යෝජනා කර ඇති අතර, තවමත් ක්රියාත්මක කර නොමැති විශේෂාංග ණයට ගනු ලැබේ. ක්රියාකාරීත්වයේ යම් මට්ටමකට ළඟා වූ පසු, Libc පද්ධතිය සඳහා සම්පූර්ණ ප්රතිස්ථාපනයක් ලෙස නව Libc භාවිතා කළ හැක. අපි x86-64 ගෘහ නිර්මාණ ශිල්පය, ලිනක්ස් සහ ස්ථිතික සම්බන්ධ කිරීම සඳහා සහය ඇතිව ආරම්භ කිරීමට සැලසුම් කරමු (ගතික පැටවීම, සම්බන්ධ කිරීම සහ අතිරේක ගෘහ නිර්මාණ ශිල්පය දෙවනුව ක්රියාත්මක කෙරේ).
ව්යාපෘතිය තවමත් සංවර්ධනයේ මුල් අවධියේ පවතී, නමුත් මූලික ඉලක්ක දැනටමත් අර්ථ දක්වා ඇත:
- මොනොලිතික් කට්ටලයකට වඩා කැටිති පුස්තකාලයක් ලබා දීමේ දර්ශනයට අනුකූලව මොඩියුලරිටි සහ සංවර්ධනය;
- මාතයන් තුළ ස්ථිතික සම්බන්ධ කිරීම සඳහා සහාය
PIE (තනතුර-ස්වාධීන ක්රියාත්මක කළ හැකි) සහ PIE නොමැතිව. ස්ථිතිකව සම්බන්ධිත ක්රියාත්මක කළ හැකි සඳහා CRT (C ධාවන කාලය) සහ PIE පූරණය සැපයීම; - පවතින යෙදුම්වලට අවශ්ය POSIX එකතු කිරීම් සහ සමහර පද්ධති-විශේෂිත දිගු සමඟ බොහෝ සම්මත C පුස්තකාල ශ්රිත සඳහා සහාය;
- විකුණුම්කරු-විශේෂිත දිගු සමඟ ප්රවේශම් වන්න සහ අවශ්ය විට පමණක් ඒවා එක් කරන්න. තෙවන පාර්ශවීය දිගු සඳහා සහය සම්බන්ධයෙන්, Clang සහ libc++ ව්යාපෘතිවල ප්රවේශය භාවිතා කිරීමට යෝජිතය;
- LLVM මෙවලම් කට්ටලය භාවිතයෙන් සංවර්ධනයේ හොඳම පරිචයන් භාවිතා කිරීම, එනම් ආරම්භයේ සිටම සනීපාරක්ෂක සහ ෆස් පරීක්ෂණ භාවිතා කිරීම.
සක්රීය LLVM සංවර්ධකයන්ගෙන් එකකි
ඔබේ අදහසත්
- නිවැරදි, ගැළපෙන සහ උසස් තත්ත්වයේ Libc සංවර්ධනය කිරීම සහ නඩත්තු කිරීම ඉතා අපහසු කාර්යයකි. ගැටළුව ඇත්තේ කේත ප්රමාණයේ නොව, නිවැරදි හැසිරීම සහ අතුරුමුහුණත් ක්රියාවට නැංවීමේ දුෂ්කරතා සහතික කිරීමේදී, C/C++ හි මෙතෙක් ලියා ඇති යෙදුම්වල විශාල ස්ථරය මෙන්ම වෙනත් භාෂාවල යෙදුම්, භාවිතා කරන ධාවන කාලය සැලකිල්ලට ගනිමින්. Libc විසිනි. සූක්ෂ්මතාවයන් සැලකිල්ලට නොගෙන ප්රවේශයක් ලබා ගැනීම, පවතින බොහෝ වැඩසටහන් වලට Libc සමඟ වැඩ කිරීමට නොහැකි වනු ඇත, නමුත් එවැනි ව්යාපෘතියක් පාරිභෝගිකයින්ට උනන්දුවක් නොදක්වයි.
- ආයතනික සංවර්ධනය Libc විනාශ කළ හැකි නමුත්, එය පුළුල් භාවිතය සඳහා තල්ලු කළ හැකි අතර, එහි ප්රතිඵලයක් ලෙස යෙදුම්වල ගැළපුම සහතික කිරීම සඳහා හැක් එකතු කිරීමේ අවශ්යතාවය ඇති වේ. ආයතනික විවෘත මූලාශ්ර ව්යාපෘතියක අනුග්රහය යටතේ සංවර්ධනය කිරීම ප්රජාවගේ අවශ්යතාවලට හානියක් වන පරිදි සමාගමේ අවශ්යතා සහ විසඳුම් දෙසට බ්ලැන්කට්ටුවක් ඇද දමයි. උදාහරණයක් ලෙස, ඔබ වෙනත් වැඩසටහනක දෝෂයක් නිසා ඇති වන ගැටලුවක් හඳුනා ගන්නේ නම්, පාලිත සංවර්ධනයේදී, දෝෂය නිවැරදි කිරීමට වඩා Libc මෙම දෝෂය සමඟ ගැළපෙන බව සහතික කිරීම පහසුය. Apple විසින් මෙම අරමුණු සඳහා BSD libc fork භාවිතා කරන අතර Google Fuchsia හි musl fork භාවිතා කරයි. musl සංවර්ධකයාගේ අත්දැකීම නම් බලපත්ර ගැටළු පැහැදිලි කිරීම සඳහා ප්රධාන වශයෙන් නීතීඥයින් ඔහුව සම්බන්ධ කර ගත් නමුත් ඔහුගේ ශාඛාවලට නිෂ්ඵල සහ බාධාකාරී වෙනස්කම් කිරීමට පෙර තාක්ෂණික තොරතුරු පැහැදිලි කිරීමට කිසි විටෙකත් සම්බන්ධ කර නොගත් බවයි.
- libc සංවර්ධනයේ ඒක සංස්කෘතියක් නොමැති වීම සහ පුද්ගල පාලනයට වඩා සම්මුතිය මත පදනම් වූ ප්රමිතීන් කෙරෙහි අවධානය යොමු කිරීම, විශේෂිත ක්රියාත්මක කිරීම්වලට බැඳී නොසිට ප්රමිති භාවිතා කිරීමට යෙදුම් සංවර්ධකයින් පොළඹවයි. musl හි කතුවරයා තම පුස්තකාලය LLVM හි ඇතුළත් කිරීමට මෙන්ම LLVM තුළ libc සංවර්ධනයට විරුද්ධ වන්නේ එබැවිනි, මන්ද මේ අවස්ථාවේ දී libc හි ස්වාධීන ස්වභාවය නැති වී යම් ක්රියාත්මක කිරීමක් පළමු පන්තියේ විසඳුමක් බවට පත්වේ. LLVM, සහ අනෙකුත් සියල්ල දෙවන පන්තියේ විසඳුමක් බවට පත් වේ.
මූලාශ්රය: opennet.ru