By: Marcus (m.delete@this.bitsnbites.eu), August 9, 2022 1:25 pm
Room: Moderated Discussions
Konrad Schwarz (no.spam.delete@this.no.spam) on August 2, 2022 10:00 am wrote:
> Rayla (rayla.delete@this.example.com) on July 29, 2022 2:09 pm wrote:
> > The binaries are all stripped as part of the Buildroot configuration. Is there another approach
> > I should take to get a more representative figure than just looking at the binary size?
>
> I wonder if the architecture-specific size(1) command (e.g., riscv-unknown-elf-size)
> gives an unbiased answer? It would be its intended purpose.
>
> Furthermore, after stripping both debug sections and the symbol table, the file size
> of the ELF should be a good proxy. Obviously, programmer-defined static variables and
> const static variables, which should be pretty much the same size for all architectures
> with the same word-length, introduce bias; on the other hand, this puts the
>
> Another idea is to look at the ELF program segment table with e.g. riscv-unknown-linux-gnu-objdump
> -p; the read-only section(s) might be a good indication. Come to think of
> it, this is probably what an ELF-based size does.
One thing that I find very tricky when comparing binary sizes between architectures is the effect of statically linked system/compiler libraries, such as libgcc and newlib. These may vary a fair bit depending on differemt implementations of standard functions or compiler helper functions, which OS you're targeting, your crt0 (what system functions are called from crt0), and what code you compile. E.g. which system functions are pulled in, and are you using some odd compiler type/construct that pulls in lots of helper functions (e.g. certain floating-point operations that are not supported in hardware).
As an example, my firmware code broke the ROM size limit in my current project when I updated to a newer version of newlib, since the exit() code in newlib had been refactored in a way that pulled in more library functions. My solution was to drop the exit() call from my crt0, to make the firmware fit in the ROM again.
I assume that something large enough like busybox would be fairly representative, though.
> Rayla (rayla.delete@this.example.com) on July 29, 2022 2:09 pm wrote:
> > The binaries are all stripped as part of the Buildroot configuration. Is there another approach
> > I should take to get a more representative figure than just looking at the binary size?
>
> I wonder if the architecture-specific size(1) command (e.g., riscv-unknown-elf-size)
> gives an unbiased answer? It would be its intended purpose.
>
> Furthermore, after stripping both debug sections and the symbol table, the file size
> of the ELF should be a good proxy. Obviously, programmer-defined static variables and
> const static variables, which should be pretty much the same size for all architectures
> with the same word-length, introduce bias; on the other hand, this puts the
>
> Another idea is to look at the ELF program segment table with e.g. riscv-unknown-linux-gnu-objdump
> -p; the read-only section(s) might be a good indication. Come to think of
> it, this is probably what an ELF-based size does.
One thing that I find very tricky when comparing binary sizes between architectures is the effect of statically linked system/compiler libraries, such as libgcc and newlib. These may vary a fair bit depending on differemt implementations of standard functions or compiler helper functions, which OS you're targeting, your crt0 (what system functions are called from crt0), and what code you compile. E.g. which system functions are pulled in, and are you using some odd compiler type/construct that pulls in lots of helper functions (e.g. certain floating-point operations that are not supported in hardware).
As an example, my firmware code broke the ROM size limit in my current project when I updated to a newer version of newlib, since the exit() code in newlib had been refactored in a way that pulled in more library functions. My solution was to drop the exit() call from my crt0, to make the firmware fit in the ROM again.
I assume that something large enough like busybox would be fairly representative, though.
