Um dos desenvolvedores do Google na lista de discussão do LLVM sobre o desenvolvimento de uma biblioteca C padrão multiplataforma (Libc) como parte do projeto LLVM. Por uma série de razões, o Google não está satisfeito com a atual libc (glibc, musl) e a empresa está a caminho de desenvolver uma nova implementação, que se propõe a ser desenvolvida como parte do LLVM.
Os desenvolvimentos do LLVM foram recentemente usados como base para a construção das ferramentas de montagem do Google. A ideia principal é que se o Google já começou a desenvolver sua libc, então por que não desenvolver imediatamente seu sistema como parte do LLVM, que já oferece sua própria biblioteca padrão para C++ (Libc++), mas não possui uma biblioteca padrão semelhante para C (libc).
O desenvolvimento está previsto para ser feito em etapas, aumentando gradativamente a funcionalidade. As primeiras opções são propostas para serem desenhadas como uma camada entre a aplicação e o sistema Libc, da qual serão emprestadas funcionalidades que ainda não foram implementadas. Depois de atingir um certo nível de funcionalidade, o novo Libc pode ser usado como um substituto completo do sistema Libc. Planejamos começar com suporte para arquitetura x86-64, Linux e vinculação estática (carregamento dinâmico, vinculação e arquiteturas adicionais serão implementadas secundariamente).
O projeto ainda está em fase inicial de desenvolvimento, mas os objetivos básicos já foram definidos:
- Modularidade e desenvolvimento de acordo com a filosofia de entregar uma biblioteca granular ao invés de um conjunto monolítico;
- Suporte para vinculação estática em modos (Executáveis independentes de posição) e sem PIE. Fornecimento de CRT (tempo de execução C) e carregador PIE para executáveis vinculados estaticamente;
- Suporte para a maioria das funções padrão da biblioteca C, com adições POSIX e algumas extensões específicas do sistema exigidas pelos aplicativos existentes;
- Tenha cuidado com extensões específicas do fornecedor e adicione-as apenas quando necessário. Em relação ao suporte para extensões de terceiros, propõe-se utilizar a abordagem dos projetos Clang e libc++;
- Usando as melhores práticas de desenvolvimento usando o kit de ferramentas LLVM, como o uso de sanitizer e testes de fuzz desde o início.
Um dos desenvolvedores ativos do LLVM É claro que faz sentido enviar a libc como parte do kit de ferramentas LLVM, mas normalmente, quando tal necessidade surge, eles usam a biblioteca musl, que é bem escrita, suporta várias arquiteturas e fornece a funcionalidade necessária, incluindo suporte para dinâmica vinculando. Pode ser justificado incorporar o musl no LLVM e desenvolvê-lo como um fork sincronizado com o projeto principal.
Sua opinião também O autor do projeto Musl, que tentou argumentar porque a proposta do Google e a inclusão da Libc na distribuição 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 as dificuldades de implementação de interfaces, tendo em conta a enorme camada de aplicações já escritas em C/C++, bem como aplicações em outras linguagens, cujo tempo de execução é utilizado por Libc. Uma abordagem frontal sem levar em conta as nuances só levará ao fato de que muitos programas existentes não serão capazes de trabalhar com o Libc, mas tal projeto não será do interesse dos consumidores.
- O desenvolvimento corporativo pode arruinar a Libc, mas empurrá-la para uso generalizado, resultando na necessidade de adicionar hacks para garantir a compatibilidade nas aplicações. O desenvolvimento sob os auspícios de um projeto corporativo de código aberto irá puxar o cobertor para as necessidades e soluções da empresa, em detrimento dos interesses da comunidade. Por exemplo, se você identificar um problema causado por um bug em outro programa, no desenvolvimento controlado é mais fácil garantir que a Libc é compatível com esse bug do que consertar o bug em si. A Apple usa o fork libc do BSD para esses fins, e o Google usa o fork musl no Fuchsia. A experiência do desenvolvedor musl é que ele foi contatado principalmente por advogados para esclarecer questões de licenciamento, mas nunca foi contatado para esclarecer detalhes técnicos antes de fazer alterações inúteis e perturbadoras em suas filiais.
- A ausência de uma monocultura no desenvolvimento da libc e um foco em padrões orientados por consenso em vez de controle individual, o que motiva os desenvolvedores de aplicativos a usar padrões em vez de ficarem vinculados a implementações específicas. É por isso que o autor do musl é contra a inclusão de sua biblioteca no LLVM, bem como contra o desenvolvimento da libc dentro do LLVM, pois neste caso a natureza independente da libc é perdida e uma determinada implementação torna-se uma solução de primeira classe para LLVM e todos os outros tornam-se uma solução de segunda classe.
Fonte: opennet.ru