Um dos desenvolvedores da empresa Google na lista de discussão do LLVM o tema do desenvolvimento de uma biblioteca padrão C multiplataforma (Libc) no âmbito do projeto LLVM. Por várias razões, o Google não está satisfeito com as libc atuais (glibc, musl) e está em processo de desenvolvimento de uma nova implementação, que se propõe a ser desenvolvida como parte do LLVM.
Os desenvolvimentos do LLVM têm sido usados recentemente como base para a construção da ferramenta de compilação do Google. A ideia principal é que, se o Google já começou a desenvolver sua própria libc, por que não desenvolver sua própria implementação como parte do LLVM, que já oferece sua biblioteca padrão para C++ (Libc++), mas não possui uma biblioteca padrão equivalente para C (Libc).
O desenvolvimento será realizado por etapas, aumentando gradualmente a funcionalidade. As primeiras versões devem ser formuladas como uma camada entre a aplicação e a Libc do sistema, da qual serão tiradas funcionalidades ainda não implementadas. Após alcançar um determinado nível de funcionalidade, a nova Libc poderá ser utilizada como um substituto completo da Libc do sistema. O início está planejado com suporte para a arquitetura x86-64, Linux e vinculação estática (o carregamento dinâmico, a composição e arquiteturas adicionais serão implementados em segundo lugar).
O projeto ainda está em sua fase inicial de desenvolvimento, mas os objetivos básicos já foram definidos:
- Modularidade e desenvolvimento de acordo com a filosofia de entrega de uma biblioteca granular, e não um conjunto monolítico;
- Suporte para vinculação estática em modos com (executáveis independentes de posição) e sem PIE. Fornecimento de CRT (tempo de execução C) e carregador PIE para arquivos executáveis vinculados estaticamente;
- Suporte para a maioria das funções da biblioteca padrão C com complementos POSIX e algumas extensões específicas de sistema que são demandadas em aplicações existentes;
- Abordagem cautelosa em relação a extensões específicas do fabricante, adicionando-as somente quando necessário. Quanto ao suporte a extensões de terceiros, sugere-se aplicar a abordagem dos projetos Clang e libc++;
- Uso de boas práticas de desenvolvimento utilizando ferramentas LLVM, como a aplicação de sanitizers e testes de fuzzing desde o início.
Um dos desenvolvedores ativos do LLVM , que a inclusão da libc como parte da ferramenta LLVM não é sem sentido, mas geralmente, em casos como esse, utiliza-se a biblioteca musl, que é bem escrita, suporta diversas arquiteturas e fornece a funcionalidade necessária, inclusive suporte para vinculação dinâmica. A inclusão da musl no LLVM e seu desenvolvimento como um fork sincronizado com o projeto principal podem ser justificados.
Sua opinião também o autor do projeto Musl, que tentou argumentar por que a proposta do Google e a inclusão da Libc no fornecimento do LLVM são ideias muito ruins:
- Desenvolver e manter uma Libc correta, compatível e de alta qualidade é uma tarefa muito difícil. O problema não está na quantidade de código, mas em garantir o comportamento correto e nas dificuldades de implementar interfaces considerando a enorme quantidade de aplicações já escritas em C/C++, bem como aplicações em outras linguagens cujo runtime utiliza a Libc. Uma abordagem direta, sem considerar nuances, apenas resultará em muitas aplicações existentes não funcionando com a Libc, o que tornaria tal projeto desinteressante para os consumidores.
- O desenvolvimento corporativo pode prejudicar a Libc, mas promover seu uso amplo, resultando na necessidade de adicionar hacks para garantir compatibilidade em aplicações. O desenvolvimento sob a égide de um projeto aberto corporativo puxará a coberta em direção às necessidades e soluções da empresa, em detrimento dos interesses da comunidade. Por exemplo, se um problema for identificado devido a um erro em outro programa sob controle, fica mais fácil garantir a compatibilidade da Libc com esse erro do que corrigir o próprio erro. A Apple utiliza um fork da libc BSD para esses fins, enquanto o Google aplica um fork da musl no Fuchsia. A experiência do desenvolvedor da musl mostra que ele foi contatado principalmente por advogados para esclarecer questões de licenciamento, mas nunca foi consultado sobre detalhes técnicos antes de alterações inúteis e que comprometeriam a funcionalidade serem incorporadas em seus forks.
- A falta de monocultura no desenvolvimento do libc e a orientação para padrões em desenvolvimento baseados em consenso, em vez de gestão unilateral, motiva os desenvolvedores de aplicativos a utilizarem padrões e não ficarem atados a implementações específicas. É por isso que o autor do musl se opõe à inclusão de sua biblioteca no LLVM, assim como à desenvolvimento do libc dentro do LLVM, já que nesse caso se perde a natureza independente do libc e uma implementação específica se torna a solução de primeira classe para o LLVM, enquanto as demais ficam em segundo plano.
Fonte: opennet.ru
