Solod leva parte da biblioteca do Go para fora do sistema operacional

Proposta e modelo freestanding

Solod é um subconjunto de Go traduzido para C que passou a incorporar parte da biblioteca padrão de Go. O objetivo descrito é tornar o maior número possível de pacotes independente de qualquer implementação de libc ou ambiente específico de sistema operacional. Dos 37 pacotes padrão atualmente presentes no projeto, 31 funcionam em modo freestanding.

Em C, o modo hosted oferece a biblioteca padrão completa, ou recursos adicionais como POSIX. Já o modo freestanding, selecionado por -ffreestanding e normalmente vinculado com -nostdlib, não fornece printf, malloc, memcpy, sistema de arquivos, relógio ou fonte de entropia. Esse ambiente é útil para microcontroladores, módulos WebAssembly, núcleos e outros contextos sem sistema operacional. Solod distingue os dois modos em tempo de compilação por meio de um cabeçalho comum e de implementações condicionais em cada pacote.

Técnicas de implementação

O projeto aproveita recursos oferecidos pelo compilador, como __builtin_trap para asserções e pânico, __builtin_alloca para alocação na pilha e operações atômicas __atomic_xxx. Os builtins de memória, porém, não resolvem tudo: em cópias grandes ou cujo tamanho só é conhecido em tempo de execução, o compilador ainda pode gerar chamadas aos símbolos reais de memcpy, memmove, memset e memcmp. Por isso, o ambiente precisa fornecê-los, seja por meio da plataforma, seja com implementações em C. Funções como memchr e strlen não são disponibilizadas pelo compilador e precisam ser escritas.

Quando não há implementação pronta, algoritmos independentes presentes na biblioteca de Go, como conversões de texto em número e operações de math/bits, podem ser portados para C de maneira relativamente mecânica. Para memória, Solod evita depender de uma implementação própria de malloc: define uma interface de alocador e recomenda que o chamador forneça a memória. Arenas, que alocam linearmente em um buffer fixo e podem ser reiniciadas, permitem controlar explicitamente capacidade e liberação.

Outra adaptação é substituir ponteiros por valores quando possível. Em vez de alocar um leitor de strings no heap, por exemplo, a função construtora pode retornar a estrutura diretamente. Isso não é exclusivo de ambientes freestanding, mas reduz alocações e dependências de gerenciamento de memória.

Hardware, limites e testes

Recursos dependentes do alvo, como saída, relógio, pausa e geração de números aleatórios, são expostos como hooks que o código do usuário implementa conforme o hardware. Solod fornece definições fracas padrão: descartar saída pode ser aceitável, mas inventar uma data não é; a ausência de entropia criptograficamente segura provoca pânico, enquanto geradores determinísticos podem servir como alternativa quando segurança não é necessária. Pacotes como os e net, que exigiriam muito código específico, são bloqueados em modo freestanding por um erro no cabeçalho, em vez de falharem apenas na vinculação ou na execução.

A validação usa os mesmos testes dos pacotes em modo hosted, executados em um módulo wasm32-freestanding por meio de um pequeno adaptador WASI e do wasmtime. A conclusão do autor resume a abordagem: separar os modos em tempo de compilação, usar builtins, implementar ou portar o que faltar, preferir alocadores explícitos e valores, definir hooks com padrões fracos, rejeitar pacotes incompatíveis e testar a compilação freestanding diretamente.