Los desarrolladores de Google quieren desarrollar su propio libc para LLVM

LLVM_Logo

Uno de los desarrolladores de Google presentó en la lista de correo de LLVM el tema del desarrollo de una biblioteca C estándar multiplataforma (Libc) dentro del marco del proyecto LLVM.

Por varias razones, Google no está satisfecho con el libc actual (glibc, musl) y la compañía 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 la base para construir herramientas de Google.

El desarrollo está planeado para ser gradual, aumentando gradualmente la funcionalidad. Se propone que las primeras opciones tengan la forma de una capa intermedia entre la aplicación y el sistema libc, de donde se tomarán prestadas las características no realizadas.

Después de alcanzar un cierto nivel de funcionalidad, el nuevo Libc se puede usar como un reemplazo completo del sistema Libc.

Se planea comenzar con el soporte de la arquitectura x86-64, Linux y el enlace estático (la carga dinámica, el empaquetado y las arquitecturas adicionales se implementarán en segundo lugar).

El proyecto aún se encuentra en la etapa inicial de desarrollo, pero los objetivos básicos ya se han definido:

  • La modularidad y el desarrollo de acuerdo con la filosofía de suministrar una biblioteca granular, en lugar de un conjunto monolítico.
  • Soporte de enlace estático en modos con PIE (ejecutables independientes de la posición) y sin PIE. Proporcionar CRT (tiempo de ejecución de C) y cargador de PIE para archivos ejecutables enlazados estáticamente.
  • Admite la mayoría de las funciones de la biblioteca C estándar con los complementos POSIX y algunas extensiones específicas del sistema que se solicitan en las aplicaciones existentes.
  • Actitud cuidadosa hacia las extensiones específicas del proveedor y solo agregándolas cuando sea necesario. Para el soporte de extensiones de terceros, se propone utilizar el enfoque de proyectos Clang y libc ++.
  • Uso de prácticas ejemplares en el desarrollo utilizando herramientas de LLVM, como la aplicación de desinfectantes y la eliminación de pruebas desde el principio.

Uno de los desarrolladores activos de LLVM indicó que la entrega de libc como parte del kit de herramientas de LLVM no carece de significado, pero generalmente con tal necesidad utilizan la biblioteca musl, que está bien escrita, admite varias arquitecturas y proporciona la funcionalidad necesaria, incluida la vinculación dinámica.

Se puede justificar la incorporación de Musl en LLVM y su desarrollo como un fork sincronizado con el proyecto principal.

Su opinión también fue expresada por el autor del proyecto Musl, que trató de argumentar por qué la propuesta de Google y la inclusión de Libc en la entrega de LLVM son muy malas ideas:

Desarrollar y mantener el libc correcto, compatible y de alta calidad es una tarea muy difícil. El problema no está en la cantidad de código, sino en proporcionar el comportamiento correcto.

Y las dificultades con la implementación de interfaces, teniendo en cuenta el enorme depósito de aplicaciones escritas en C / C ++, así como las aplicaciones en otros idiomas cuyo tiempo de ejecución es utilizado por Libc.

El acercamiento a la frente sin tener en cuenta los matices solo llevará al hecho de que muchos programas existentes no podrán trabajar con Libc, pero tal proyecto no será de interés para los consumidores.

El desarrollo corporativo puede arruinar a la Libc, pero impulsar el uso generalizado, cuyo resultado será la necesidad de agregar hacks para garantizar la compatibilidad en las aplicaciones.

El desarrollo bajo los auspicios de un proyecto abierto corporativo llevará la cobertura hacia las necesidades y decisiones de la empresa, en detrimento de los intereses de la comunidad.

Por ejemplo, en el caso de identificar un problema causado por un error en otro programa propio, en el desarrollo bajo control, es más fácil garantizar la compatibilidad de Libc con este error que corregir el error en sí.

Por su parte Apple usa la bifurcación BSD libc para estos propósitos y Google usa la bifurcación en Fuchsia. La experiencia del desarrollador de Musl sugiere que los abogados lo contactaron principalmente para aclarar los problemas de licencia.

Fuente: http://lists.llvm.org

Sé el primero en comentar

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.