Wilco (wilco.dijkstra.delete@this.ntlworld.com) on July 28, 2022 3:45 am wrote:
> Rayla (rayla.delete@this.example.com) on July 27, 2022 1:44 pm wrote:
> > I did some code density comparisons for a gemlog post I was writing. This is just the size
> > of the buildroot-generated busybox binary, across every buildroot-supported target except
> > CSky, with a preference for "typical" embedded configs when possible and with -Os as the
> > optimization flag. I thought folks here might find it at least a little interesting.
>
> If you literally mean size of binary then that is obviously not the same as code density. A binary contains
> huge amounts of stuff besides the actual code. Even the size command doesn't give accurate measurements since
> it includes rodata and unwind tables (and some targets emit unwind tables by default, others do not, plus there
> are several different formats in use).

Parts of what is .text on one architecture are .rodata on another.
In theory, could be .data on the yet another.

> An example of how much clutter there is in a typical binary:
>
> > ls -al ./gcc/bin/gcc
> 6805424
> > size ./gcc/bin/gcc
> text data bss dec hex filename
> 1347722 15184 17832 1380738 151182
> > objdump -h ./gcc/bin/gcc | grep .text
> 13 .text 000b0b3e 0000000000403130 0000000000403130 00003130 2**4
>
> So the size of the actual code is just 10.6% of the total
> binary, and 53.7% of the size reported by size...
>
> Wilco


STM32 (Cortex-M4) project that is currently on my desk:
Binary size - 45428
.isr_vector 428
.text 41172
.rodata 2960
.init_array 4
.fini_array 4
.data 844

So, in my case, binary image size is quite representative.


BTW, I once tried to figure out why Xilinx uBlaze (or should we already call it AMD uBlaze?) binaries are so huge. Without digging deeply, my conclusion was that the blame lays on gcc code generator which is very significantly worse than code generators for other similar ISAs.