Qual é o vinculador de ouro?

O linker gold foi projetado como um linker específico de ELF, com a intenção de produzir um linker mais rápido e de fácil manutenção do que o BFD ld (o linker GNU binutils “tradicional”). Como efeito colateral, ele é realmente capaz de vincular programas muito grandes usando menos memória do que o BFD ld, presumivelmente porque há menos camadas de abstração para lidar e porque os dados do vinculador as estruturas são mapeadas mais diretamente para o formato ELF.

Não tenho certeza se há muita documentação que aborda especificamente as diferenças de design entre os dois vinculadores e seu efeito no uso da memória. Há uma série muito interessante de artigos sobre linkers de Ian Lance Taylor, o autor de vários linkers GNU, que explica muitas das decisões de design que levaram a gold. Ele escreve que

O vinculador que estou trabalhando agora, chamado ouro, será seja meu terceiro. É exclusivamente um linker ELF. Mais uma vez, o objetivo é a velocidade, neste caso sendo mais rápido do que meu segundo vinculador. Esse linker diminuiu significativamente ao longo dos anos, adicionando suporte para ELF e para bibliotecas compartilhadas. Este suporte foi corrigido em vez de ter sido projetado.

(O segundo linker é BFD ld.)

Comentários

• seria o nome ' gold ' vêm da leitura ' ld ' como ' lead ', e o ouro obviamente é mais valioso do que o chumbo?
• @Aganju Não, ' é apenas go prefixado a ld.

O O gold linker foi escrito para tornar o processo de link consideravelmente mais rápido. De acordo com o autor de ouro Ian Lance Taylor

No momento, o ouro tem apenas um vantagem significativa sobre o vinculador existente: é mais rápido. Em grandes programas C ++, eu avaliei sua execução cinco vezes mais rápida.

Ele está comparando o desempenho do vinculador ouro com o vinculador GNU tradicional. gold (ao contrário do vinculador GNU) não usa a biblioteca BFD para processar arquivos de objeto.

A limitação do gold é que (ao contrário do GNU linker, que pode processar muitos tipos de arquivo de objeto), ele só pode vincular arquivos de objeto no formato ELF.

Em relação aos problemas que você enfrentou ao usar o GNU linker, aqui está uma resposta interessante a uma pergunta semelhante no SO de Michael Adam:

O vinculador ouro até encontrou alguns problemas de dependência em nosso código, pois parece ser mais correto do que o clássico no que diz respeito a alguns detalhes. Veja, por exemplo este commit do Samba.

gold vs ld benchmark

Publiquei um benchmark sintético concreto de ld vs gold em: https://stackoverflow.com/questions/3476093/replacing-ld-with-gold-any-experience/53921263#53921263

Resumo de resultados: o gold foi 2x a 3x vezes mais rápido que o ld.

Esse ganho de tempo pode ser uma grande virada de jogo em projetos C ++ complexos com modelos e geração de código fora de controle, porque a etapa de link envolve todos os arquivos do projeto e, ao contrário da compilação, deve ser feito sempre, mesmo se você alterar apenas um único arquivo .cpp.

Portanto, um tempo de link lento torna o ciclo de desenvolvimento insuportável e é provavelmente o principal motivo O Google investiu recursos nele. Imagine os ganhos de esperar 10s em vez de 30s para cada alteração de arquivo trivial.

Os ganhos de tempo do benchmark sintético também concordaram com os ganhos reais que tive em um projeto complexo do mundo real (gem5), como também mencionado nessa resposta.

Existem três linkers disponíveis em sistemas GNU / Linux modernos:

• ld , mantido por GNU binutils,
• ouro , mantido por GNU binutils, “ainda em teste beta”,
• lld , desenvolvido como parte do projeto LLVM.

Para benchmarks de velocidade, consulte: https://www.phoronix.com/scan.php?page=article&item=lld4-linux-tests&num=2 TL, DR: lld é o mais rápido, seguido por gold, seguido por ld

Algumas fontes dizem que o projeto ouro foi estagnada , e a estrutura de pacotes no Fedora reflete isso.