A polêmica sobre toolchains e glibc

Afinal, vale a pena consertar o glibc (e outros projetos que suportam apenas GCC) para compilar com LLVM? É melhor apenas substituí-los por alternativas que já suportam LLVM? É melhor usar o GCC e o LLVM, cada um para seus respectivos projetos com suporte?

Estas são algumas das perguntas a serem respondidas por Adrian Ratiu, da Collabora neste artigo que você confere a seguir. Ele vai ressaltar que, nos últimos anos, a cadeia de ferramentas LLVM tem visto um crescente desenvolvimento e adoção junto com a cadeia de ferramentas GNU mais antiga e mais estável. O surgimento deste novo mundo de duas grandes cadeias de ferramentas está trazendo desafios e questões para projetos que precisam oferecer suporte a ambos, em particular a biblioteca GNU C (glibc), que suporta apenas GCC.

Esta postagem é uma exploração a partir dessas perguntas, mas não tenta dar respostas definitivas. A intenção aqui não é causar divisões e controvérsias, mas aumentar a conscientização, descrevendo partes do status quo atual e encorajar a colaboração. O elefante óbvio na sala, o licenciamento, é deixado de fora, apesar de ser um tópico muito importante.

A carga de suporte do conjunto de ferramentas

Distribuições que usam ou permitem que LLVM/Clang seja usado como compilador principal (Yocto / OE, Gentoo / ChromeOS, OpenMandriva, Alpine e outros, talvez até Android possa ser contado aqui) são forçadas a usar libcs ??diferentes ou manter um conjunto de ferramentas GCC apenas por construir um pequeno subconjunto de pacotes no centro do qual é tipicamente glibc. Isso não é ideal, considerando a necessidade de correções de bugs e suporte a novos recursos de HW, ambos conjuntos de ferramentas que requerem manutenção ativa.

Descartar o GCC e fazer o downstream de patches em projetos individuais para suportar o Clang é difícil porque os patches quebram nas atualizações (a menos que você bifurque e nunca volte a fundir) e pode introduzir bugs ou regressões, especialmente no caso de glibc onde o diff é grande e complexo. Pequenos patches como configuração, correções de compilação cruzada ou backports de correção de bugs podem ser aceitáveis ??no downstream, mas manter algo como suporte LLVM no downstream é inviável, portanto, o suporte de primeira classe e testes cuidadosos para evitar regressões devem acontecer idealmente no projeto upstream.

O problema glibc

Ao construir um sistema com LLVM/Clang, o problema mais comum é a biblioteca GNU C, que é amplamente usada e confiável. A biblioteca C em geral é parte da definição do sistema operacional básico e alguns outros projetos importantes como o systemd só podem ser construídos especificamente com a implementação GNU da lib padrão. Glibc é provavelmente o mais problemático para construir com LLVM / Clang (pelo menos dos projetos GNU) devido à sua dependência de extensões GNU toolchain ou comportamentos GCC não padrão específicos ou bugs. Isso é compreensível, considerando a idade e o propósito do projeto.

O Glibc construído pelo LLVM deve ser alcançável se considerarmos o esforço bem-sucedido para adicionar suporte Clang de primeira classe ao kernel do Linux, que também é um projeto complexo e historicamente vinculado ao GCC. O problema é: a que custo e quando o custo do glibc + LLVM excede o tempo e esforço necessários para usar um libc diferente ou manter um conjunto de ferramentas GCC apenas para glibc? Pelo menos em teoria, trocar as bibliotecas C deve ser muito mais fácil do que trocar o Linux por outro kernel, então podemos assumir que o custo é menor. O mesmo vale para manter o GCC por perto.

Existem alguns ramos “clangify” na glibc upstream (por exemplo shebs/clangify), mas eles são baseados nas versões 2.26-2.29 e o desenvolvimento parece ter parado nos últimos anos.

Comportamentos divergentes de conjuntos de ferramentas

Às vezes, o Clang e o GCC podem funcionar como substitutos imediatos um do outro, mas nem sempre é esse o caso. Exemplos óbvios são os diferentes sinalizadores de construção ou extensões que requerem sinalizadores de ativação do Clang especiais. Um exemplo mais sutil é que o Clang “afirma” suportar -std = gnu99, embora não ofereça suporte a funções aninhadas que fazem parte do gnu99. As coisas ficam complicadas quando não há um padrão explícito para governar um comportamento e os projetos podem depender do que quer que aconteça para funcionar em uma cadeia de ferramentas, normalmente o GCC. Por exemplo. o GNU assembler é mais permissivo do que o Clang assembler que, entre outras coisas, rejeita instruções ambíguas . Pode não estar totalmente claro em qual projeto está o “bug”.

Código de suporte do projeto

Devido às diferenças entre LLVM e GCC como acima, vários projetos acabam tendo que #ifdef código específico da cadeia de ferramentas, que pode ser uma fonte de bugs, além de tornar o código mais feio em geral. Isso é muito bem relatado em uma apresentação do desenvolvedor do OpenMandriva Bernhard Rosenkränzer na EuroLLVM 2019. Os exemplos são tristes e cômicos ao mesmo tempo. Como contexto para o exemplo a seguir, o Clang define __GNUC__ == 4.

#if __GNUC__> = 5
do_something_sane ();
#outro
assume_the_compiler_sucks ();
#fim se