Why is the binary generated by my gcc cross compiler so large?

After getting a gcc toolchain for ARM built the next step was to build a simple "Hello world" application. I put together something simple to set an output and toggle it:

#include "stm32f10x.h"
#include "stm32f10x_rcc.h"
#include "stm32f10x_gpio.h"

const static int DelayCount = 2500000;

void Delay()
{
volatile int delayValue;

delayValue = DelayCount;
while(delayValue)
{
delayValue--;
}
}

int main()
{
// enable gpio c clock, IOPCEN bit
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

// configure PC12 as output, open drain
GPIO_TypeDef* gpio = GPIOC;
GPIO_InitTypeDef gpioInit;
GPIO_StructInit(&gpioInit);
gpioInit.GPIO_Mode = GPIO_Mode_Out_OD;
gpioInit.GPIO_Pin = GPIO_Pin_12;
GPIO_Init(gpio, &gpioInit);

// loop forever
while(1)
{
// output 1 on PC12
GPIO_SetBits(gpio, GPIO_Pin_12);

Delay();

// output 0 on PC12
GPIO_ResetBits(gpio, GPIO_Pin_12);

Delay();
}

return 1;
}

After building this program in Eclipse, this site was helpful among others, it was ~770k. Figuring it was due to debugging symbols I tried running 'strip' on the elf and using 'objcopy -O binary in.elf out.bin'.

Ran readelf -s on the elf file to see what symbols were present and saw tons of functions that I didn't expect to see, things like malloc.

Turns out there were a few issues.

- Eclipse wasn't seeing the assembly files as they had '.s' extension instead of '.S'. Renaming the appropriate assembly file resolved this issue.

- Gcc/linker wasn't being properly configured to remove unused symbols

• Options to add for the compiler:
• -fdata-sections -ffunction-sections
• Causes the compiler to place code and data in separate sections.
• Options to add for the linker:
• --gc-sections
• Causes the linker to remove unused sections.

After these changes the elf went from ~770k down to ~589k and after the conversion to binary file the file was down to under 2k.