binutils size utility suppresses zero-length sections

Is what you described caused by CodeSourcery tool chain or by this GCC ARM embedded tool chain? If former, please report it to CodeSourcery. Otherwise, would you please provide a reduced test case for us to reproduce?

Sorry I was not clear, Terry. The suppression of size's display of zero-length sections is something I'm seeing in this (v4.9) GCC ARM tool chain. The CodeSourcery version that *DOES NOT SUPPRESS* the output is 2014.05-28 (gcc version 4.8.3).

If you have a copy of the CodeSourcery tool chain, simply building an .elf file with the zero-length .flashpatch section in the linker script (which I believe is a standard section in all ARM script examples), you will see different output of arm-none-eabi-size. I will try to cobble a very reduced set of files for you to try.

I want to reiterate that this is probably a linker issue. When I run CodeSourcery's arm-none-eabi-size -A on an elf file generated by this site's 4.9 gcc, the CodeSourcery size utility suppresses the zero-size sections of the 4.9-generated elf file. So, it seems it is the .elf file that is causing the issue--rather than the version of the size utility. I'll try to generate a matrix of effects between 4.8 and 4.9 versions of the gcc/g++ and the size utilities asap.

Issue confirmed. If I link my project with Sourcery ld, the zero-length section will be kept as below:

terguo01@terry-pc01:minimum$ arm-none-eabi-size minimum-CM0.axf -A
minimum-CM0.axf :
section size addr
.text 140 0
.flashpatch 0 536870912
.data 0 268435456
.bss 0 268435456
.stack_dummy 3072 268435456
.comment 112 0
.ARM.attributes 40 0
Total 3364

If use ld from arm embedded tool chain, there will be no such section. May I know why this zero-length section matters?

Terry,

Thanks for confirming this. I always do a 'size' on the generated .elf file when we build; it gives me a nice summary of the state of the executable.

One reason for wanting to know about zero-length sections is to know if a section is zero-length! (One might not have sized a section correctly, and would want to know if that section was not set up properly in the linker script.

But, this issue specifically broke the build for my makefile. After the .text section, we save some flash for other purposes, and give it a location in the STM32 flash memory map. I like to know after each build how much program space I have left (part of my summary data when I build the .elf). The section just after .text is currently zero-length in our build (let's call it .spare_flash). I use grep and awk to parse the output of size, then subtract the location of the start of .spare_flash from the start of .text (yields the total amount of .text I make available), then subtract the size of .text. This yields the remaining programming space I have to work with. It's just nice to see it.

Because .spare_flash does not now show up in 'size' output, the bash code in my makefile gets confused. 'size' has always emitted the zero-length sections in the past, so this broke our expected build output.

Again, thank you for your attention to this.

Related fixes have been identified from upstream binutils and will be back ported to 4.9 update 1 release. Mark this as Solved and please continue the discuss in corresponding bug entry if needed.