Un dos desenvolvedores de Google na lista de correo de LLVM sobre o desenvolvemento dunha biblioteca C estándar multiplataforma (Libc) como parte do proxecto LLVM. Por varias razóns, Google non está satisfeito coa actual libc (glibc, musl) e a empresa está en camiño de desenvolver unha nova implementación, que se propón desenvolver como parte de LLVM.
Os desenvolvementos de LLVM utilizáronse recentemente como base para construír as ferramentas de montaxe de Google. A idea principal é que se Google xa comezou a desenvolver a súa libc, entón por que non desenvolver inmediatamente o seu sistema como parte de LLVM, que xa ofrece a súa propia biblioteca estándar para C++ (Libc++), pero non ten unha biblioteca estándar similar para C. (libc).
O desenvolvemento está previsto que se realice por etapas, aumentando gradualmente a funcionalidade. As primeiras opcións proponse para ser deseñadas como unha capa entre a aplicación e o sistema Libc, da que se tomarán prestadas funcións que aínda non foron implementadas. Despois de acadar un certo nivel de funcionalidade, o novo Libc pódese usar como substituto completo do sistema Libc. Pretendemos comezar co soporte para a arquitectura x86-64, Linux e a ligazón estática (a carga dinámica, a ligazón e as arquitecturas adicionais implementaranse secundariamente).
O proxecto aínda está na fase inicial de desenvolvemento, pero os obxectivos básicos xa están definidos:
- Modularidade e desenvolvemento de acordo coa filosofía de ofrecer unha biblioteca granular en lugar dun conxunto monolítico;
- Soporte para ligazóns estáticas en modos (Executables independentes da posición) e sen PIE. Proporcionando CRT (tempo de execución C) e cargador PIE para executables ligados estáticamente;
- Soporte para a maioría das funcións estándar da biblioteca C, con adicións de POSIX e algunhas extensións específicas do sistema requiridas polas aplicacións existentes;
- Teña coidado coas extensións específicas do provedor e só engádeas cando sexa necesario. En canto ao soporte para extensións de terceiros, proponse utilizar o enfoque dos proxectos Clang e libc++;
- Utilizar as mellores prácticas no desenvolvemento mediante o kit de ferramentas LLVM, como o uso de desinfectantes e probas de fuzz desde o principio.
Un dos desenvolvedores activos de LLVM Está claro que ten sentido enviar libc como parte do kit de ferramentas LLVM, pero normalmente, cando xorde esa necesidade, usan a biblioteca musl, que está ben escrita, admite varias arquitecturas e proporciona a funcionalidade necesaria, incluíndo soporte para dinámicas. vinculación. Pode estar xustificado incorporar musl en LLVM e desenvolvelo como un fork sincronizado co proxecto principal.
A túa opinión tamén O autor do proxecto Musl, que tratou de argumentar por que a proposta de Google e a inclusión de Libc na distribución LLVM son moi malas ideas:
- Desenvolver e manter un Libc correcto, compatible e de alta calidade é unha tarefa moi difícil. O problema non está na cantidade de código, senón en garantir un comportamento correcto e as dificultades na implementación de interfaces, tendo en conta a enorme capa de aplicacións escritas nunca en C/C++, así como aplicacións noutras linguaxes, cuxo tempo de execución se utiliza. por Libc. Un enfoque frontal sen ter en conta os matices só levará ao feito de que moitos programas existentes non poderán funcionar con Libc, pero entón tal proxecto non será de interese para os consumidores.
- O desenvolvemento corporativo pode arruinar Libc, pero empurralo para un uso xeneralizado, o que provoca a necesidade de engadir hackeos para garantir a compatibilidade nas aplicacións. O desenvolvemento baixo os auspicios dun proxecto corporativo de código aberto tirará a manta cara ás necesidades e solucións da empresa, en detrimento dos intereses da comunidade. Por exemplo, se identifica un problema que é causado por un erro noutro programa, no desenvolvemento controlado é máis fácil asegurarse de que Libc é compatible con este erro que corrixir o propio erro. Apple usa o fork libc BSD para estes fins e Google usa o fork musl en fucsia. A experiencia do desenvolvedor de musl é que foi contactado principalmente por avogados para aclarar problemas de licenza, pero nunca foi contactado para aclarar detalles técnicos antes de facer cambios inútiles e perturbadores nas súas sucursais.
- A ausencia dun monocultivo no desenvolvemento de libc e un foco nos estándares impulsados polo consenso en lugar do control individual, o que motiva aos desenvolvedores de aplicacións a usar estándares en lugar de estar ligados a implementacións específicas. É por iso que o autor de musl está en contra da inclusión da súa biblioteca en LLVM, así como contra o desenvolvemento de libc dentro de LLVM, xa que neste caso pérdese a natureza independente de libc e certa implementación convértese nunha solución de primeira para LLVM e todos os demais convértense nunha solución de segunda clase.
Fonte: opennet.ru