Salah satu pengembang dari Google di milis LLVM tentang pengembangan perpustakaan C standar multi-platform (Libc) sebagai bagian dari proyek LLVM. Karena sejumlah alasan, Google tidak puas dengan libc (glibc, musl) saat ini dan perusahaan sedang mengembangkan implementasi baru, yang diusulkan untuk dikembangkan sebagai bagian dari LLVM.
Perkembangan LLVM baru-baru ini digunakan sebagai dasar untuk membuat alat perakitan Google. Ide utamanya adalah jika Google sudah mulai mengembangkan libc-nya, mengapa tidak segera mengembangkan sistemnya sebagai bagian dari LLVM, yang sudah menawarkan perpustakaan standarnya sendiri untuk C++ (Libc++), tetapi tidak memiliki perpustakaan standar serupa untuk C ( libc).
Pengembangan rencananya akan dilakukan secara bertahap, secara bertahap meningkatkan fungsionalitas. Opsi pertama diusulkan untuk dirancang sebagai lapisan antara aplikasi dan sistem Libc, dari mana fitur-fitur yang belum diimplementasikan akan dipinjam. Setelah mencapai tingkat fungsionalitas tertentu, Libc baru dapat digunakan sebagai pengganti lengkap untuk sistem Libc. Kami berencana untuk memulai dengan dukungan untuk arsitektur x86-64, Linux, dan tautan statis (pemuatan dinamis, tautan, dan arsitektur tambahan akan diimplementasikan secara sekunder).
Proyek ini masih dalam tahap awal pengembangan, namun tujuan dasarnya telah ditentukan:
- Modularitas dan pengembangan sesuai dengan filosofi menghadirkan perpustakaan granular, bukan kumpulan monolitik;
- Dukungan untuk tautan statis dalam mode (Executable yang tidak bergantung pada posisi) dan tanpa PIE. Menyediakan CRT (runtime C) dan pemuat PIE untuk executable yang terhubung secara statis;
- Dukungan untuk sebagian besar fungsi perpustakaan C standar, dengan tambahan POSIX dan beberapa ekstensi khusus sistem yang diperlukan oleh aplikasi yang ada;
- Berhati-hatilah dengan ekstensi khusus vendor dan hanya tambahkan jika diperlukan. Mengenai dukungan untuk ekstensi pihak ketiga, diusulkan untuk menggunakan pendekatan proyek Clang dan libc++;
- Menggunakan praktik terbaik dalam pengembangan menggunakan toolkit LLVM, seperti penggunaan sanitizer dan pengujian fuzz sejak awal.
Salah satu pengembang LLVM yang aktif Jelas bahwa masuk akal untuk mengirimkan libc sebagai bagian dari toolkit LLVM, tetapi biasanya, ketika kebutuhan seperti itu muncul, mereka menggunakan perpustakaan musl, yang ditulis dengan baik, mendukung berbagai arsitektur, dan menyediakan fungsionalitas yang diperlukan, termasuk dukungan untuk dinamis menghubungkan. Mungkin dibenarkan untuk menyematkan musl ke dalam LLVM dan mengembangkannya sebagai fork yang disinkronkan dengan proyek utama.
Pendapat Anda juga Penulis proyek Musl, yang mencoba menjelaskan mengapa proposal Google dan penyertaan Libc dalam distribusi LLVM adalah ide yang sangat buruk:
- Mengembangkan dan memelihara Libc yang benar, kompatibel, dan berkualitas tinggi adalah tugas yang sangat sulit. Masalahnya bukan pada jumlah kodenya, namun pada memastikan perilaku yang benar dan kesulitan dalam mengimplementasikan antarmuka, dengan mempertimbangkan banyaknya lapisan aplikasi yang pernah ditulis dalam C/C++, serta aplikasi dalam bahasa lain, yang runtime-nya digunakan. oleh Libc. Pendekatan langsung tanpa mempertimbangkan nuansa hanya akan mengarah pada fakta bahwa banyak program yang ada tidak akan dapat bekerja dengan Libc, tetapi proyek semacam itu tidak akan menarik bagi konsumen.
- Pengembangan perusahaan dapat merusak Libc, namun mendorongnya untuk digunakan secara luas, sehingga memerlukan penambahan peretasan untuk memastikan kompatibilitas dalam aplikasi. Pembangunan di bawah naungan proyek open source perusahaan akan menutupi kebutuhan dan solusi perusahaan, sehingga merugikan kepentingan masyarakat. Misalnya, jika Anda mengidentifikasi masalah yang disebabkan oleh bug di program lain, dalam pengembangan terkontrol lebih mudah untuk memastikan bahwa Libc kompatibel dengan bug ini daripada memperbaiki bug itu sendiri. Apple menggunakan fork libc BSD untuk tujuan ini, dan Google menggunakan fork musl di Fuchsia. Pengalaman pengembang musl adalah dia dihubungi terutama oleh pengacara untuk mengklarifikasi masalah perizinan, namun tidak pernah dihubungi untuk mengklarifikasi rincian teknis sebelum membuat perubahan yang tidak berguna dan mengganggu pada cabangnya.
- Tidak adanya monokultur dalam pengembangan libc dan fokus pada standar yang didorong oleh konsensus daripada kontrol tunggal, yang memotivasi pengembang aplikasi untuk menggunakan standar daripada terikat pada implementasi tertentu. Itulah sebabnya penulis musl menentang penyertaan perpustakaannya di LLVM, serta menentang pengembangan libc di dalam LLVM, karena dalam kasus ini sifat independen libc hilang dan implementasi tertentu menjadi solusi kelas satu untuk LLVM, dan yang lainnya menjadi solusi kelas dua.
Sumber: opennet.ru