Uno de los desarrolladores de Google en la lista de correos de LLVM el tema del desarrollo de una biblioteca estándar de C multiplataforma (Libc) como parte del proyecto LLVM. Por varias razones, Google no está satisfecho con las libc actuales (glibc, musl) y la empresa está en el camino de desarrollar una nueva implementación, que se propone desarrollar como parte de LLVM.
Los avances de LLVM se están utilizando últimamente como base para construir herramientas de compilación en Google. La idea principal es que, si Google ya ha comenzado a desarrollar su libc, ¿por qué no desarrollar su sistema dentro de LLVM, que ya ofrece su biblioteca estándar para C++ (Libc++) pero no tiene una biblioteca estándar similar para C (Libc)?
Se planea llevar a cabo el desarrollo de manera gradual, aumentando la funcionalidad poco a poco. Las primeras versiones se propone que se organicen como una capa entre la aplicación y la Libc del sistema, de la cual se tomarán características aún no implementadas. Después de alcanzar un cierto nivel de funcionalidad, la nueva Libc podrá utilizarse como un reemplazo completo de la Libc del sistema. Se empezará con el soporte para la arquitectura x86-64, Linux y enlace estático (la carga dinámica, la vinculación y arquitecturas adicionales se implementarán en una segunda fase).
El proyecto está en su fase inicial de desarrollo, pero ya se han definido objetivos básicos:
- Modularidad y desarrollo de acuerdo con la filosofía de ofrecer una biblioteca granular, en lugar de un conjunto monolítico;
- Soporte para enlace estático en modos con (ejecutables independientes de posición) y sin PIE. Proporcionar CRT (tiempo de ejecución de C) y cargador PIE para archivos ejecutables vinculados estáticamente;
- Soporte para la mayoría de las funciones de la biblioteca estándar de C, con adiciones de POSIX y algunas extensiones específicas del sistema, requeridas en aplicaciones existentes;
- Trato cauteloso hacia las extensiones específicas de los proveedores y su adición solo cuando sea necesario. En cuanto al soporte para extensiones de terceros, se propone aplicar el enfoque de los proyectos Clang y libc;
- Uso de prácticas ejemplares en el desarrollo utilizando las herramientas de LLVM, como la aplicación de sanitizadores y pruebas de fuzzing desde el principio.
Uno de los desarrolladores activos de LLVM , que la inclusión de libc en el conjunto de herramientas de LLVM tiene sentido, pero generalmente, en situaciones así, se utiliza la biblioteca musl, que está bien escrita, soporta diversas arquitecturas y proporciona la funcionalidad necesaria, incluyendo el soporte de enlace dinámico. La integración de musl en LLVM y el desarrollo de un fork sincronizado con el proyecto principal puede ser justificada.
También el autor del proyecto Musl, quien intentó argumentar por qué la propuesta de Google de incluir Libc en la distribución de LLVM es una muy mala idea:
- Desarrollar y mantener una Libc correcta, compatible y de alta calidad es una tarea muy difícil. El problema no está en el volumen de código, sino en asegurar un comportamiento correcto y las dificultades con la implementación de interfaces teniendo en cuenta la enorme cantidad de aplicaciones escritas en C/C++, así como aplicaciones en otros lenguajes cuyo runtime utiliza Libc. Un enfoque directo sin considerar los matices solo llevará a que muchos programas existentes no puedan funcionar con Libc, y un proyecto así no será atractivo para los consumidores.
- El desarrollo corporativo puede arruinar Libc, pero impulsar su uso generalizado resultará en la necesidad de añadir hacks para asegurar la compatibilidad en las aplicaciones. El desarrollo bajo el auspicio de un proyecto de código abierto corporativo tenderá a beneficiar las necesidades y soluciones de la empresa, a expensas de los intereses de la comunidad. Por ejemplo, en caso de descubrir un problema causado por un error en otro de sus programas, en un desarrollo controlado es más fácil asegurar la compatibilidad de Libc con ese error, que corregir el propio error. Apple utiliza para estos fines un fork de BSD libc, y Google utiliza en Fuchsia un fork de musl. La experiencia del desarrollador de musl indica que principalmente ha sido contactado por abogados para aclarar cuestiones de licenciación, pero nunca se le ha consultado sobre detalles técnicos antes de implementar en sus bifurcaciones cambios innecesarios que interrumpen su funcionamiento.
- La ausencia de monocultivo en el desarrollo de libc y la orientación hacia estándares desarrollados en base al consenso, en lugar de la gestión unitaria, motiva a los desarrolladores de aplicaciones a utilizar estándares, en lugar de atarse a implementaciones específicas. Por esta razón, el autor de musl está en contra de incluir su biblioteca en LLVM, así como de desarrollar libc dentro de LLVM, ya que en este caso se pierde la independencia de libc y una implementación determinada se convierte en la solución de primer nivel para LLVM, mientras que todas las demás son de segundo nivel.
Fuente: opennet.ru
