Một trong những nhà phát triển của Google trên danh sách gửi thư LLVM về việc phát triển thư viện C tiêu chuẩn đa nền tảng (Libc) như một phần của dự án LLVM. Vì một số lý do, Google không hài lòng với libc hiện tại (glibc, musl) và công ty đang trên đường phát triển một triển khai mới, được đề xuất phát triển như một phần của LLVM.
Sự phát triển LLVM gần đây đã được sử dụng làm cơ sở để xây dựng các công cụ lắp ráp của Google. Ý tưởng chính là nếu Google đã bắt đầu phát triển libc của mình thì tại sao không phát triển ngay hệ thống của mình như một phần của LLVM, vốn đã cung cấp thư viện chuẩn riêng cho C++ (Libc++), nhưng không có thư viện chuẩn tương tự cho C ( libc).
Việc phát triển dự kiến sẽ được thực hiện theo từng giai đoạn, tăng dần chức năng. Các tùy chọn đầu tiên được đề xuất thiết kế dưới dạng một lớp giữa ứng dụng và hệ thống Libc, từ đó các tính năng chưa được triển khai sẽ được mượn. Sau khi đạt đến một mức chức năng nhất định, Libc mới có thể được sử dụng để thay thế hoàn toàn cho Libc của hệ thống. Chúng tôi dự định bắt đầu với việc hỗ trợ kiến trúc x86-64, Linux và liên kết tĩnh (tải động, liên kết và các kiến trúc bổ sung sẽ được triển khai thứ hai).
Dự án vẫn đang ở giai đoạn phát triển ban đầu, nhưng các mục tiêu cơ bản đã được xác định:
- Tính mô đun và phát triển phù hợp với triết lý cung cấp một thư viện dạng hạt thay vì một bộ nguyên khối;
- Hỗ trợ liên kết tĩnh trong các chế độ (Các tệp thực thi độc lập với vị trí) và không có PIE. Cung cấp CRT (thời gian chạy C) và trình tải PIE cho các tệp thực thi được liên kết tĩnh;
- Hỗ trợ hầu hết các chức năng thư viện C tiêu chuẩn, với các bổ sung POSIX và một số tiện ích mở rộng dành riêng cho hệ thống mà các ứng dụng hiện có yêu cầu;
- Hãy cẩn thận với các tiện ích mở rộng dành riêng cho nhà cung cấp và chỉ thêm chúng khi cần thiết. Về hỗ trợ cho các tiện ích mở rộng của bên thứ ba, đề xuất sử dụng cách tiếp cận của các dự án Clang và libc++;
- Sử dụng các phương pháp hay nhất trong quá trình phát triển bằng bộ công cụ LLVM, chẳng hạn như sử dụng tính năng khử trùng và kiểm tra lông tơ ngay từ đầu.
Một trong những nhà phát triển LLVM tích cực Rõ ràng là việc gửi libc như một phần của bộ công cụ LLVM là hợp lý, nhưng thông thường, khi có nhu cầu như vậy, họ sử dụng thư viện musl, được viết tốt, hỗ trợ nhiều kiến trúc khác nhau và cung cấp chức năng cần thiết, bao gồm cả hỗ trợ cho động liên kết. Có thể hợp lý khi nhúng musl vào LLVM và phát triển nó như một nhánh phân nhánh được đồng bộ hóa với dự án chính.
Ý kiến của bạn cũng Tác giả của dự án Musl, người đã cố gắng tranh luận tại sao đề xuất của Google và việc đưa Libc vào bản phân phối LLVM lại là những ý tưởng rất tồi:
- Phát triển và duy trì một Libc chính xác, tương thích và chất lượng cao là một nhiệm vụ rất khó khăn. Vấn đề không nằm ở số lượng mã mà ở việc đảm bảo hành vi chính xác và những khó khăn trong việc triển khai giao diện, có tính đến lớp ứng dụng khổng lồ từng được viết bằng C/C++, cũng như các ứng dụng bằng ngôn ngữ khác, thời gian chạy của chúng được sử dụng của Libc. Cách tiếp cận trực tiếp mà không tính đến các sắc thái sẽ chỉ dẫn đến thực tế là nhiều chương trình hiện có sẽ không thể hoạt động với Libc, nhưng khi đó một dự án như vậy sẽ không được người tiêu dùng quan tâm.
- Sự phát triển của công ty có thể hủy hoại Libc, nhưng lại đẩy nó vào sử dụng rộng rãi, dẫn đến nhu cầu bổ sung thêm các bản hack để đảm bảo khả năng tương thích trong các ứng dụng. Sự phát triển dưới sự bảo trợ của một dự án nguồn mở của công ty sẽ kéo theo các nhu cầu và giải pháp của công ty, gây phương hại đến lợi ích của cộng đồng. Ví dụ: nếu bạn xác định một sự cố do lỗi trong chương trình khác gây ra, thì trong quá trình phát triển có kiểm soát, việc đảm bảo rằng Libc tương thích với lỗi này sẽ dễ dàng hơn là tự sửa lỗi đó. Apple sử dụng nhánh libc BSD cho những mục đích này và Google sử dụng nhánh musl trong Fuchsia. Kinh nghiệm của nhà phát triển musl là anh ta chủ yếu được các luật sư liên hệ để làm rõ các vấn đề cấp phép, nhưng chưa bao giờ được liên hệ để làm rõ các chi tiết kỹ thuật trước khi thực hiện những thay đổi vô ích và mang tính đột phá đối với các chi nhánh của mình.
- Việc thiếu độc canh trong phát triển libc và tập trung vào các tiêu chuẩn dựa trên sự đồng thuận thay vì kiểm soát cá nhân, điều này thúc đẩy các nhà phát triển ứng dụng sử dụng các tiêu chuẩn thay vì bị ràng buộc với việc triển khai cụ thể. Đó là lý do tại sao tác giả của musl phản đối việc đưa thư viện của mình vào LLVM, cũng như phản đối việc phát triển libc trong LLVM, vì trong trường hợp này tính chất độc lập của libc bị mất và việc triển khai nhất định trở thành giải pháp hạng nhất cho LLVM và tất cả những giải pháp khác đều trở thành giải pháp hạng hai.
Nguồn: opennet.ru