Uno de los desarrolladores de Google. en la lista de correo de LLVM sobre el desarrollo de una biblioteca C estándar multiplataforma (Libc) como parte del proyecto LLVM. Por varias razones, Google no está satisfecho con la libc actual (glibc, musl) y la empresa está en camino de desarrollar una nueva implementación, que se propone desarrollar como parte de LLVM.
Los desarrollos de LLVM se han utilizado recientemente como base para crear las herramientas de ensamblaje de Google. La idea principal es que si Google ya ha comenzado a desarrollar su libc, ¿por qué no desarrollar inmediatamente su sistema como parte de LLVM, que ya ofrece su propia biblioteca estándar para C++ (Libc++), pero no tiene una biblioteca estándar similar para C? (libc).
Está previsto que el desarrollo se lleve a cabo por etapas, aumentando gradualmente la funcionalidad. Se propone diseñar las primeras opciones como una capa entre la aplicación y el sistema Libc, de la cual se tomarán prestadas características que aún no se han implementado. Después de alcanzar un cierto nivel de funcionalidad, el nuevo Libc se puede utilizar como un reemplazo completo del sistema Libc. Planeamos comenzar con soporte para arquitectura x86-64, Linux y enlaces estáticos (la carga dinámica, los enlaces y arquitecturas adicionales se implementarán de forma secundaria).
El proyecto aún se encuentra en la etapa inicial de desarrollo, pero ya se han definido los 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 enlaces estáticos en modos. (ejecutables independientes de la posición) y sin PIE. Proporcionar CRT (tiempo de ejecución C) y cargador PIE para ejecutables vinculados estáticamente;
- Soporte para la mayoría de las funciones de la biblioteca C estándar, con adiciones POSIX y algunas extensiones específicas del sistema requeridas por las aplicaciones existentes;
- Tenga cuidado con las extensiones específicas del proveedor y agréguelas solo cuando sea necesario. En cuanto al soporte para extensiones de terceros, se propone utilizar el enfoque de los proyectos Clang y libc++;
- Utilizar las mejores prácticas en el desarrollo utilizando el kit de herramientas LLVM, como el uso de desinfectantes y pruebas fuzz desde el principio.
Uno de los desarrolladores activos de LLVM Está claro que tiene sentido enviar libc como parte del conjunto de herramientas LLVM, pero generalmente, cuando surge tal necesidad, usan la biblioteca musl, que está bien escrita, admite varias arquitecturas y proporciona la funcionalidad necesaria, incluido el soporte para dinámica. enlace. Puede estar justificado incorporar musl en LLVM y desarrollarlo como una bifurcación sincronizada con el proyecto principal.
tu opinion tambien El autor del proyecto Musl, que intentó argumentar por qué la propuesta de Google y la inclusión de Libc en la distribución LLVM son muy malas ideas:
- Desarrollar y mantener una Libc correcta, compatible y de alta calidad es una tarea muy difícil. El problema no está en la cantidad de código, sino en garantizar el comportamiento correcto y las dificultades en la implementación de interfaces, teniendo en cuenta la enorme capa de aplicaciones jamás escritas en C/C++, así como aplicaciones en otros lenguajes, cuyo tiempo de ejecución se utiliza. por Libc. Un enfoque frontal sin tener en cuenta los matices sólo conducirá al hecho de que muchos programas existentes no podrán funcionar con Libc, pero entonces dicho proyecto no será de interés para los consumidores.
- El desarrollo corporativo puede arruinar Libc, pero impulsar su uso generalizado, lo que resulta en la necesidad de agregar trucos para garantizar la compatibilidad en las aplicaciones. El desarrollo bajo los auspicios de un proyecto corporativo de código abierto irá en detrimento de las necesidades y soluciones de la empresa, en detrimento de los intereses de la comunidad. Por ejemplo, si identifica un problema causado por un error en otro programa, en el desarrollo controlado es más fácil garantizar que Libc sea compatible con este error que corregir el error en sí. Apple utiliza la bifurcación BSD libc para estos fines y Google utiliza la bifurcación musl en fucsia. La experiencia del desarrollador de musl es que fue contactado principalmente por abogados para aclarar cuestiones de licencia, pero nunca fue contactado para aclarar detalles técnicos antes de realizar cambios inútiles y perjudiciales en sus sucursales.
- La ausencia de una monocultura en el desarrollo de libc y un enfoque en estándares impulsados por el consenso en lugar del control individual, lo que motiva a los desarrolladores de aplicaciones a utilizar estándares en lugar de estar atados a implementaciones específicas. Es por eso que el autor de musl está en contra de la inclusión de su biblioteca en LLVM, así como en contra del desarrollo de libc dentro de LLVM, ya que en este caso se pierde la naturaleza independiente de libc y una determinada implementación se convierte en una solución de primera clase para LLVM y todos los demás se convierten en una solución de segunda clase.
Fuente: opennet.ru