Hi,
Sorry for possible off-topic but I did not find any better place to ask my question. Unfortunately there is no mail list for yagarto ARM compiler. But I hope my question is simple and can be usefully for other developers.
Below is an output of
arm-none-eabi-size -B -t -common <LIST OF OBJECT FILES>
text data bss dec hex filename
496 0 0 496 1f0 _output/startup_stm32f2xx.o
779 0 16 795 31b _output/main.o
….
skip
….
1787 4 208 1999 7cf _output/tasks.o
796 0 56 852 354 _output/timers.o
338 4 0 342 156 _output/port.o
652 0 128 780 30c _output/croutine.o
262 4 16404 16670 411e _output/heap_2.o
132 0 0 132 84 _output/list.o
55073 176 61845 117094 1c966 (TOTALS)
Size of target .elf file:
arm-none-eabi-size -B _output/CM5.elf
text data bss dec hex filename
24800 68 73852 98720 181a0 _output/CM5.elf
My question is why there is a difference between total BSS size of all objects = 61845
and BSS size in elf file = 73852
What is the actual size of used memory? My CPU has 128K And I do not want to waist 73852-61845 bytes.
Thanks.
yagarto+FreeRTOS. BSS elf size vs actual size
yagarto+FreeRTOS. BSS elf size vs actual size
Have a look in the map file. It should tell you the start address of each object in .bss. Perhaps there is a lot of padding for alignment.
Are you compiling as C++ or C?
Is there any debugger code or stubs added? Try a release build without debug info.
Are you compiling as C++ or C?
Is there any debugger code or stubs added? Try a release build without debug info.
yagarto+FreeRTOS. BSS elf size vs actual size
I’m building with C via own Makefile and ld script.
I have removed debug options -g and -ggdb3 but situation did not change. Map file looks also much more optimistic then size output:
…
.bss 0x20000044 0x9f84 load address 0x0800e11c
0x20000044 . = ALIGN (0x4)
0x20000044 _sbss = .
…
…
0x20009fc8 . = ALIGN (0x4)
0x20009fc8 _ebss = .
0x20009fc8 PROVIDE (end, _ebss)
0x20009fc8 PROVIDE (_end, _ebss) ._usrstack 0x20009fc8 0x100 load address 0x080180a0
0x20009fc8 . = ALIGN (0x4)
0x20009fc8 _susrstack = .
0x2000a0c8 . = (. + _Minimum_Stack_Size)
*fill* 0x20009fc8 0x100 00
0x2000a0c8 . = ALIGN (0x4)
0x2000a0c8 _eusrstack = .
0x2000a0c8 __exidx_start = .
0x2000a0c8 __exidx_end = . So according to map file my BSS is 0x9f84 = 40836 dec long.
How can it be?
I have removed debug options -g and -ggdb3 but situation did not change. Map file looks also much more optimistic then size output:
…
.bss 0x20000044 0x9f84 load address 0x0800e11c
0x20000044 . = ALIGN (0x4)
0x20000044 _sbss = .
…
…
0x20009fc8 . = ALIGN (0x4)
0x20009fc8 _ebss = .
0x20009fc8 PROVIDE (end, _ebss)
0x20009fc8 PROVIDE (_end, _ebss) ._usrstack 0x20009fc8 0x100 load address 0x080180a0
0x20009fc8 . = ALIGN (0x4)
0x20009fc8 _susrstack = .
0x2000a0c8 . = (. + _Minimum_Stack_Size)
*fill* 0x20009fc8 0x100 00
0x2000a0c8 . = ALIGN (0x4)
0x2000a0c8 _eusrstack = .
0x2000a0c8 __exidx_start = .
0x2000a0c8 __exidx_end = . So according to map file my BSS is 0x9f84 = 40836 dec long.
How can it be?