یکی از توسعه دهندگان گوگل در لیست پستی LLVM درباره توسعه یک کتابخانه استاندارد C چند پلتفرمی (Libc) به عنوان بخشی از پروژه LLVM. به دلایلی، گوگل از libc فعلی (glibc، musl) راضی نیست و این شرکت در راه توسعه یک پیاده‌سازی جدید است که پیشنهاد می‌شود به عنوان بخشی از LLVM توسعه یابد.
پیشرفت های LLVM اخیراً به عنوان پایه ای برای ساخت ابزارهای اسمبلی گوگل استفاده شده است. ایده اصلی این است که اگر گوگل از قبل شروع به توسعه libc خود کرده است، پس چرا سیستم خود را به عنوان بخشی از LLVM که در حال حاضر کتابخانه استاندارد خود را برای C++ (Libc++) ارائه می‌کند، توسعه نمی‌دهد، اما کتابخانه استاندارد مشابهی برای C ندارد. (libc).
برنامه ریزی شده است که توسعه به صورت مرحله ای انجام شود و عملکرد به تدریج افزایش یابد. گزینه های اول پیشنهاد شده است که به عنوان یک لایه بین برنامه و سیستم Libc طراحی شوند که از آن ویژگی هایی که هنوز پیاده سازی نشده اند به عاریت گرفته می شود. پس از رسیدن به سطح خاصی از عملکرد، Libc جدید می تواند به عنوان یک جایگزین کامل برای سیستم Libc استفاده شود. ما قصد داریم با پشتیبانی از معماری x86-64، لینوکس و پیوند استاتیک شروع کنیم (بارگذاری پویا، پیوند و معماری های اضافی در مرحله دوم پیاده سازی خواهند شد).
این پروژه هنوز در مرحله اولیه توسعه است، اما اهداف اساسی قبلاً تعریف شده است:
- مدولار بودن و توسعه مطابق با فلسفه ارائه یک کتابخانه دانه ای به جای مجموعه یکپارچه.
- پشتیبانی از پیوند استاتیک در حالت ها (اجرای مستقل از موقعیت) و بدون PIE. ارائه CRT (زمان اجرا C) و بارگذار PIE برای فایل های اجرایی مرتبط استاتیک.
- پشتیبانی از اکثر توابع استاندارد کتابخانه C، با افزودن POSIX و برخی از برنامه های افزودنی خاص سیستم مورد نیاز برنامه های موجود.
- مراقب پسوندهای خاص فروشنده باشید و فقط در صورت لزوم آنها را اضافه کنید. با توجه به پشتیبانی از برنامه های افزودنی شخص ثالث، پیشنهاد می شود از رویکرد پروژه های Clang و libc++ استفاده شود.
- استفاده از بهترین شیوه ها در توسعه با استفاده از جعبه ابزار LLVM، مانند استفاده از ضدعفونی کننده و تست فاز از همان ابتدا.
یکی از توسعه دهندگان فعال LLVM واضح است که ارسال libc به عنوان بخشی از جعبه ابزار LLVM منطقی است، اما معمولاً هنگامی که چنین نیازی ایجاد می شود، از کتابخانه musl استفاده می کنند که به خوبی نوشته شده است، از معماری های مختلف پشتیبانی می کند و عملکردهای لازم از جمله پشتیبانی از پویا را فراهم می کند. ربط دادن. جاسازی musl در LLVM و توسعه آن به عنوان یک فورک هماهنگ با پروژه اصلی ممکن است موجه باشد.
نظر شما هم نویسنده پروژه Musl، که سعی کرد استدلال کند که چرا پیشنهاد گوگل و گنجاندن Libc در توزیع LLVM ایده های بسیار بدی هستند:
- توسعه و حفظ یک Libc صحیح، سازگار و با کیفیت کار بسیار دشواری است. مشکل در مقدار کد نیست، بلکه در حصول اطمینان از رفتار صحیح و مشکلات در پیاده سازی اینترفیس ها، با در نظر گرفتن لایه عظیم برنامه هایی که تا به حال به زبان C/C++ نوشته شده اند و همچنین برنامه هایی در زبان های دیگر است که از زمان اجرا استفاده می شود. توسط Libc. یک رویکرد پیش روی بدون در نظر گرفتن تفاوت های ظریف تنها منجر به این واقعیت می شود که بسیاری از برنامه های موجود قادر به کار با Libc نخواهند بود، اما پس از آن چنین پروژه ای مورد توجه مصرف کنندگان نخواهد بود.
- توسعه شرکتی می‌تواند Libc را خراب کند، اما آن را برای استفاده گسترده تحت فشار قرار دهد و در نتیجه نیاز به افزودن هک برای اطمینان از سازگاری در برنامه‌ها وجود دارد. توسعه تحت حمایت یک پروژه منبع باز شرکتی، پتو را به سمت نیازها و راه حل های شرکت می کشد و به ضرر منافع جامعه است. به عنوان مثال، اگر مشکلی را شناسایی کنید که توسط یک باگ در برنامه دیگری ایجاد شده است، در توسعه کنترل شده اطمینان از سازگاری Libc با این باگ آسان تر از رفع خود باگ است. اپل از فورک BSD libc برای این منظور استفاده می کند و گوگل از فورک musl در فوشیا استفاده می کند. تجربه توسعه‌دهنده musl این است که عمدتاً توسط وکلا برای شفاف‌سازی مسائل مربوط به مجوز با او تماس گرفته شد، اما قبل از ایجاد تغییرات بی‌فایده و مخرب در شعبه‌هایش، هرگز برای شفاف‌سازی جزئیات فنی با او تماس گرفته نشد.
- عدم وجود تک‌فرهنگ در توسعه libc و تمرکز بر استانداردهای مبتنی بر اجماع به‌جای کنترل فردی، که توسعه‌دهندگان برنامه‌ها را برمی‌انگیزد تا از استانداردها استفاده کنند تا اینکه به پیاده‌سازی‌های خاص گره بخورند. به همین دلیل است که نویسنده musl با گنجاندن کتابخانه خود در LLVM و همچنین با توسعه libc در LLVM مخالف است، زیرا در این حالت ماهیت مستقل libc از بین می رود و یک پیاده سازی خاص به یک راه حل درجه یک برای آن تبدیل می شود. LLVM و بقیه راه حل های درجه دوم هستند.
منبع: opennet.ru