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.

Comments

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr...

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...

Chris M.

Search This Blog