Extraindo o tamanho e a origem de todos os símbolos em um ELF

Question

Estou tentando estimar o tamanho do código dos vários componentes de um binário. Eu tenho acesso ao código-fonte e ao diretório de criação resultante contendo todos os arquivos de objeto criados. Claro, eu quero incluir apenas os símbolos que são realmente usados, então adicionar os tamanhos de todas as seções .text e .data do arquivo de objeto acabará superestimando os reais.

Como se pode determinar o tamanho e a origem de todos os símbolos usados para vincular um arquivo ELF? Algo assim seria útil:

Symbol   Size   Origin
func1    0x50   ../src/func1.o
func2    0x75   ../src/func2.o
...

E algo semelhante para todos os símbolos que são .data . O arquivo .map resultante parece ter alguns desses dados, mas parece incompleto. Duas seções que se destacam são:

Allocating common symbols
Common symbol       size              file

s_Handle         0x8               ../BUILD/src/handle.o
_main_obj        0x48              ../BUILD/src/boot.o
....

Mas há apenas algumas dezenas de símbolos listados aqui. A seção a seguir parece ter muito mais símbolos, mas parece que eles estão listados como "Descartados" no link-time:

Discarded input sections

 .text          0x00000000        0x0 /home/user/.programs/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7e-m/crti.o
 .data          0x00000000        0x0 /home/user/.programs/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7e-m/crti.o
 .bss           0x00000000        0x0 /home/user/.programs/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/armv7e-m/crti.o
 .data          0x00000000        0x0 /home/user/.programs/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/crt0.o
 .bss           0x00000000        0x0 /home/user/.programs/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/crt0.o
 .ARM.extab     0x00000000        0x0 /home/user/.programs/gcc-arm-none-eabi-5_4-2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib/armv7e-m/crt0.o
 .text._Z12notify_startv
                0x00000000       0x14 ../BUILD/./test_env.o
 .text._Z30notify_performance_coefficientPKci
                0x00000000       0x18 ../BUILD/./test_env.o
 .text._Z30notify_performance_coefficientPKcj
                0x00000000       0x18 ../BUILD/./test_env.o
 .text._Z30notify_performance_coefficientPKcd
                0x00000000       0x20 ../BUILD/./test_env.o
 .text._Z17notify_completionb
                0x00000000       0x64 ../BUILD/./test_env.o
 .text._Z21notify_completion_strbPc
                0x00000000       0x30 ../BUILD/./test_env.o
...

    

Answer 1

Você pode querer usar o Bloaty McBloatface :

The "VM SIZE" column tells you how much space the binary will take when it is loaded into memory. The "FILE SIZE" column tells you about how much space the binary is taking on disk. [...] The default breakdown in Bloaty is by sections, but many other ways of slicing the binary are supported such as symbols and segments. If you compiled with debug info, you can even break down by compile units and inlines!