What parts of the codebase are making binaries large?

Question

I have built some code for a simulator and am now trying to use TI's free toolchain to cross-compile to a target with 64kb of nvram. The compiler claims that my code is about 34kb beyond the ROM:

(...) msp430-elf/bin/ld: region `ROM' overflowed by 33716 bytes

Another line says it cannot fit the .text field into its allotted space. I cannot believe that my additions are 34kb in total, let alone causing the binaries to overflow by this amount.

• The .o files my code has added to the project are a small fraction (200kb of the 1.9MB) of the project's total, and I have taken out a great deal of components that were in the project to begin with.
• I am already passing the compiler the -Os -s flags.
• The new code has about 100 characters worth of string literals.
• My code uses many math.h functions (in fact it is the only part that does floating point arithmetic), make a call to strtod, and make a call to sprintf

Are there any tools or methods to breaks down what is causing the binaries to be so large?

Answer 1

GNU binutils has tools to help you determine the size of each symbol or just each object file.

Have a look at size for instance: https://manpages.debian.org/jessie/binutils/size.1.en.html

nm is also worth a try, as it can show the size of each symbol in the object code: https://manpages.debian.org/jessie/binutils/nm.1.en.html

Carefully inspecting the output of size and nm will give you intuition for what takes up much space and what doesn't.

Know that printf, sprintf and many of the more complex library functions can often take up quite a few kB of extra ROM.

Floating point support using soft-floats will also bloat the code compared to using hard-float, i.e. using software emulation vs. hardware instructions to handle floating point.

Sometimes the compiler will add an astonishing amount of bloat :)

Answer 2

I once also had memory issues with a tiny MSP430 controller. The TI toolchain is linking large libraries into your binary if negative values are possible or floating point is used. In my case, it was about 10% - 20% of total memory usage.

TI's free Code composer Studio does provide a very powerful memory visualization (View -> Memory Allocation)

What helped me a lot was changing the Initialization Model in the Linker settings and other optimization options. I am currently not working with an MSP430 controller so I can not tell you details any more.