Como remover símbolos C / C ++ não usados ​​com GCC e ld?

Eu preciso otimizar o tamanho do meu executável severamente ( ARMdesenvolvimento) e notei que no meu esquema de compilação atual ( gcc+ ld) os símbolos não usados ​​não estão sendo removidos.

O uso de arm-strip --strip-unneededpara os executáveis ​​/ bibliotecas resultantes não altera o tamanho de saída do executável (não tenho ideia do motivo, talvez simplesmente não possa) .

Qual seria a maneira (se houver) de modificar meu pipeline de construção, de modo que os símbolos não utilizados sejam retirados do arquivo resultante?

Eu nem sequer penso nisso, mas meu ambiente incorporado atual não é muito "forte" e economizando ainda 500Kfora de 2Mresultados em um impulso muito agradável desempenho de carregamento.

Atualizar:

Infelizmente, a gccversão atual que uso não tem a -dead-stripopção e o -ffunction-sections... + --gc-sectionsfor ldnão dá nenhuma diferença significativa para a saída resultante.

Estou chocado que isso se tornou um problema, porque eu tinha certeza que gcc + lddeveria remover automaticamente os símbolos não utilizados (por que eles ainda têm que mantê-los?).

Para o GCC, isso é realizado em duas etapas:

Primeiro compile os dados, mas diga ao compilador para separar o código em seções separadas dentro da unidade de tradução. Isso será feito para funções, classes e variáveis ​​externas usando os dois sinalizadores de compilador a seguir:

-fdata-sections -ffunction-sections

Vincule as unidades de tradução usando o sinalizador de otimização do vinculador (isso faz com que o vinculador descarte as seções não referenciadas):

-Wl,--gc-sections

Portanto, se você tivesse um arquivo chamado test.cpp que tivesse duas funções declaradas, mas uma delas não fosse usada, você poderia omitir o não usado com o seguinte comando para gcc (g ++):

gcc -Os -fdata-sections -ffunction-sections test.cpp -o test -Wl,--gc-sections

(Observe que -Os é um sinalizador de compilador adicional que diz ao GCC para otimizar o tamanho)

Para acreditar nessa thread , você precisa fornecer o -ffunction-sectionse-fdata-sections ao gcc, que colocará cada função e objeto de dados em sua própria seção. Então você dá e --gc-sectionsao GNU ld para remover as seções não utilizadas.

Você vai querer verificar seus documentos para sua versão do gcc & ld:

No entanto, para mim (OS X gcc 4.0.1), acho isso para ld

-dead_strip

Remova funções e dados que não podem ser alcançados pelo ponto de entrada ou pelos símbolos exportados.

-dead_strip_dylibs

Remova dylibs que não podem ser alcançados pelo ponto de entrada ou pelos símbolos exportados. Ou seja, suprime a geração de comandos de comando de carregamento para dylibs que não forneceram símbolos durante o link. Esta opção não deve ser usada ao vincular a um dylib que é necessário em tempo de execução por alguma razão indireta, como o dylib ter um inicializador importante.

E esta opção útil

-why_live symbol_name

Registra uma cadeia de referências a symbol_name. Aplicável apenas com -dead_strip. Isso pode ajudar a depurar por que algo que você acha que deveria ser removido da tira morta não é removido.

Também há uma observação no gcc / g ++ man que certos tipos de eliminação de código morto são executados apenas se a otimização estiver habilitada durante a compilação.

Embora essas opções / condições possam não se aplicar ao seu compilador, sugiro que você procure algo semelhante em seus documentos.

Os hábitos de programação também podem ajudar; por exemplo, adicionar staticfunções que não são acessadas fora de um arquivo específico; use nomes mais curtos para os símbolos (pode ajudar um pouco, provavelmente não muito); use sempre const char x[]que possível; ... este artigo , embora fale sobre objetos compartilhados dinâmicos, pode conter sugestões que, se seguidas, podem ajudar a diminuir o tamanho da saída binária final (se seu destino for ELF).

A resposta é -flto. Você deve passá-lo para as etapas de compilação e link, caso contrário, ele não fará nada.

Na verdade, funciona muito bem - reduziu o tamanho de um programa de microcontrolador que escrevi para menos de 50% do tamanho anterior!

Infelizmente, parecia um pouco bugado - tive casos de coisas que não foram construídas corretamente. Pode ter sido devido ao sistema de compilação que estou usando (QBS; é muito novo), mas em qualquer caso, eu recomendo que você apenas habilite-o para sua compilação final, se possível, e teste-a completamente.

Embora não seja estritamente sobre símbolos, se for pelo tamanho - sempre compilar com os sinalizadores -Ose -s. -Osotimiza o código resultante para o tamanho mínimo do executável e -sremove a tabela de símbolos e as informações de realocação do executável.

Às vezes - se o tamanho pequeno for desejado - brincar com diferentes sinalizadores de otimização pode - ou não - ter significado. Por exemplo, alternar -ffast-mathe / ou -fomit-frame-pointerpode, às vezes, economizar até dezenas de bytes.

Parece-me que a resposta fornecida por Nemo é a correta. Se essas instruções não funcionarem, o problema pode estar relacionado à versão do gcc / ld que você está usando, como um exercício, compilei um programa de exemplo usando as instruções detalhadas aqui

#include <stdio.h>
void deadcode() { printf("This is d dead codez\n"); }
int main(void) { printf("This is main\n"); return 0 ; }

Em seguida, compilei o código usando interruptores de remoção de código morto progressivamente mais agressivos:

gcc -Os test.c -o test.elf
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections
gcc -Os -fdata-sections -ffunction-sections test.c -o test.elf -Wl,--gc-sections -Wl,--strip-all

Esses parâmetros de compilação e vinculação produziram executáveis ​​de tamanho 8457, 8164 e 6160 bytes, respectivamente, a contribuição mais substancial proveniente da declaração 'strip-all'. Se você não puder produzir reduções semelhantes em sua plataforma, talvez sua versão do gcc não suporte esta funcionalidade. Estou usando gcc (4.5.2-8ubuntu4), ld (2.21.0.20110327) no Linux Mint 2.6.38-8-generic x86_64

strip --strip-unneededopera apenas na tabela de símbolos do seu executável. Na verdade, ele não remove nenhum código executável.

As bibliotecas padrão alcançam o resultado desejado, dividindo todas as suas funções em arquivos de objetos separados, que são combinados usando ar. Se você então vincular o arquivo resultante como uma biblioteca (ou seja, dar a opção -l your_libraryde ld), então ld incluirá apenas os arquivos objeto e, portanto, os símbolos que são realmente usados.

Você também pode encontrar algumas das respostas a esta questão semelhante de uso.

Não sei se isso ajudará em sua situação atual, pois este é um recurso recente, mas você pode especificar a visibilidade dos símbolos de uma maneira global. Passar -fvisibility=hidden -fvisibility-inlines-hiddenna compilação pode ajudar o vinculador a se livrar de símbolos desnecessários posteriormente. Se você estiver produzindo um executável (em oposição a uma biblioteca compartilhada), não há mais nada a fazer.

Mais informações (e uma abordagem detalhada para, por exemplo, bibliotecas) estão disponíveis no wiki do GCC .

Do manual GCC 4.2.1, seção -fwhole-program:

Suponha que a unidade de compilação atual represente o programa inteiro sendo compilado. Todas as funções e variáveis ​​públicas, com exceção de maine aquelas mescladas por atributo, externally_visibletornam-se funções estáticas e, em um efeito, são otimizadas de forma mais agressiva por otimizadores interprocedurais. Embora esta opção seja equivalente ao uso adequado de staticpalavra-chave para programas que consistem em um único arquivo, em combinação com a opção, --combineeste sinalizador pode ser usado para compilar a maioria dos programas C de escala menor, uma vez que as funções e variáveis ​​tornam-se locais para toda a unidade de compilação combinada, não para o próprio arquivo de origem único.

Você pode usar strip binário no arquivo de objeto (por exemplo, executável) para retirar todos os símbolos dele.

Nota: ele muda o próprio arquivo e não cria uma cópia.