Why does arm-none-eabi-size report the .data section to be 0 even though I am using initialized RAM?

Question

I am a bit confused by the results I am getting when I use my toolchain's (Yagarto and codesourcery) size utility. it is reporting that I am using 0 bytes in the data section. see below

$ arm-none-eabi-size.exe rest-server-example.crazy-horse.elf
   text    data     bss     dec     hex filename
  79364       0   34288  113652   1bbf4 rest-server-example.crazy-horse.elf

I know my code is using and initializing static RAM variables to values other than 0.

interestingly enough when I pass the size tool directly some of the object files that are getting linked I see .data section being reported

example:

   text    data     bss     dec     hex filename
   1648       0      20    1668     684 obj_crazy-horse/uip-nd6.o
    200      12    2652    2864     b30 obj_crazy-horse/uip-packetqueue.o
     12       0       0      12       c obj_crazy-horse/uip-split.o
   1816      24      48    1888     760 obj_crazy-horse/usb-core.o
    284       0       0     284     11c obj_crazy-horse/usb-interrupt.o
   2064      20     188    2272     8e0 obj_crazy-horse/xmac.o

Why would the elf file report 0 for the .data section when the object files that make it are reporting non-zero values?

FYI I am working on embedded software for a AT91SAM7x256 Micro

edit:

adding the CFLAGS and LDFLAGS

CFLAGS  += -O -DRUN_AS_SYSTEM -DROM_RUN  -ffunction-sections

LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map

edit #2: from the object dump we can clearly see that the .data section has data assigned to it but the size utility is not picking it up for some reason objdump link

All I am looking for is to get an exact usage of my RAM I am not trying to figure out whether one of my variables was optimized out.

edit 3: more information showing that the size utility does see something in the .data section

$ arm-none-eabi-size.exe -A -t -x  rest-server-example.crazy-horse.elf
rest-server-example.crazy-horse.elf  :
section              size       addr
.vectrom             0x34   0x100000
.text             0x10fc8   0x100038
.rodata            0x149c   0x111000
.ARM.extab           0x30   0x11249c
.ARM.exidx           0xe0   0x1124cc
.data              0x1028   0x200000
.bss               0x7bec   0x201028
.stack              0xa08   0x20f5f8
.ARM.attributes      0x32        0x0
.comment             0x11        0x0
.debug_aranges      0xc68        0x0
.debug_info       0x2b87e        0x0
.debug_abbrev      0x960b        0x0
.debug_line        0x9bcb        0x0
.debug_frame       0x4918        0x0
.debug_str         0x831d        0x0
.debug_loc        0x13fad        0x0
.debug_ranges       0x620        0x0
Total             0x7c4c5

Answer 1

My interpretation would be that the linker script creates a single loadable section, which contains the initial values of the data section and a piece of startup code that copies the data to the uninitialized data section.

This is necessary if you want to have a single image file that can be run from read-only memory, as there is no ELF loader in front then that would perform that copy for you.

Normally, this is only done in the section to segment mapping (i.e. the output sections are arranged in the linker script using the > section placement command) rather than by mapping the input section twice, but that is certainly possible as well.

The usage numbers are quite accurate: the text size is the amount of Flash space needed, the BSS size is the amount of RAM needed. Initialized data is counted twice, once for the initial data in Flash, and once for the modifiable data in RAM.