Salah satu pembangun Google yang dibentangkan dalam senarai mel LLVM topik pengembangan perpustakaan C standard lintas platform (Libc) dalam kerangka projek LLVM.
Kerana beberapa sebab, Google tidak berpuas hati dengan libc semasa (glibc, musl) dan syarikat berada di landasan yang betul untuk mengembangkan pelaksanaan baru, yang dia ingin kembangkan sebagai sebahagian dari LLVM. Perkembangan LLVM baru-baru ini digunakan sebagai asas untuk membina alat Google.
Pembangunan dirancang secara berperingkat, secara beransur-ansur meningkatkan fungsi. Pilihan pertama dicadangkan dalam bentuk lapisan antara antara aplikasi dan sistem libc, dari mana ciri-ciri yang tidak direalisasikan akan dipinjam.
Setelah mencapai tahap fungsi tertentu, Libc baru dapat digunakan sebagai pengganti lengkap untuk sistem Libc.
Ia dirancang untuk memulai dengan dukungan untuk arsitektur x86-64, Linux, dan pengikatan statik (pemuatan dinamis, pembungkusan, dan arsitektur tambahan akan dilaksanakan kedua)
Projek ini masih dalam tahap awal pembangunan, tetapi objektif asasnya telah ditentukan:
- Modulariti dan pengembangan sesuai dengan falsafah penyediaan perpustakaan berbutir, bukannya ensembel monolitik.
- Sokongan pautan statik dalam mod PIE (pelaksana bebas kedudukan) dan tanpa PIE. Sediakan pemuat CRT (C Runtime) dan PIE untuk fail boleh laku yang dihubungkan secara statik.
- Menyokong sebahagian besar fungsi perpustakaan C standard dengan pemalam POSIX dan beberapa sambungan khusus sistem yang diminta dalam aplikasi yang ada.
- Sikap berhati-hati terhadap peluasan tertentu dari pembekal dan hanya menambahkannya apabila perlu. Untuk sokongan peluasan pihak ketiga, dicadangkan untuk menggunakan pendekatan projek Clang dan libc ++.
- Menggunakan Amalan Terbaik dalam Pembangunan Menggunakan Alat LLVM, seperti penggunaan desinfektan dan penghapusan ujian dari awal.
Salah satu pembangun LLVM yang aktif menunjukkan bahawa penghantaran libc sebagai sebahagian daripada toolkit LLVM bukan tanpa makna, tetapi secara amnya dengan keperluan seperti itu mereka menggunakan perpustakaan musl, Ia ditulis dengan baik, menyokong pelbagai seni bina, dan menyediakan fungsi yang diperlukan, termasuk penghubung dinamik.
Penggabungan Musl ke dalam LLVM dan pengembangannya sebagai garpu segerak dengan projek utama dapat dibenarkan.
Pendapatnya juga dinyatakan oleh pengarang projek Musl, yang cuba membantah mengapa cadangan Google dan kemasukan Libc dalam penyampaian LLVM adalah idea yang sangat buruk:
Membangun dan mengekalkan libc yang betul, serasi dan berkualiti tinggi adalah tugas yang sangat sukar. Masalahnya bukan pada jumlah kod, tetapi dalam memberikan tingkah laku yang betul.
Dan kesukaran dengan pelaksanaan antara muka, mengingat penyimpanan besar aplikasi yang ditulis dalam C / C ++, serta aplikasi dalam bahasa lain yang runtime digunakan oleh Libc.
Pendekatan ke dahi tanpa mengambil kira nuansa hanya akan membawa kepada fakta bahawa banyak program yang ada tidak akan dapat bekerjasama dengan Libc, tetapi projek seperti itu tidak akan menarik minat pengguna.
Pembangunan korporat boleh merosakkan Libc, tetapi mendorong penggunaan yang meluas, yang akan menyebabkan perlunya menambahkan peretasan untuk memastikan keserasian dalam aplikasi.
Pembangunan di bawah naungan projek korporat terbuka akan mendorong liputan terhadap keperluan dan keputusan syarikat, sehingga merugikan kepentingan masyarakat.
Sebagai contoh, sekiranya mengenal pasti masalah yang disebabkan oleh ralat dalam program anda yang lain, dalam pembangunan yang dikendalikan, lebih mudah untuk menjamin keserasian Libc dengan ralat ini daripada membetulkan ralat itu sendiri.
Apple menggunakan garpu BSD libc untuk tujuan ini dan Google menggunakan garpu Fuchsia. Pengalaman pemaju Musl menunjukkan bahawa pengacara menghubunginya terutamanya untuk menjelaskan masalah pelesenan.
Fuente: http://lists.llvm.org