为什么arm-none-eabi-size报告.data部分为0,即使我使用初始化的RAM?

mag*_*rre 5 c embedded linker arm binutils

当我使用我的工具链(Yagarto和codesourcery)大小实用程序时,我对结果感到有些困惑.它报告我在数据部分使用0字节.见下文

$ 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
Run Code Online (Sandbox Code Playgroud)

我知道我的代码正在使用静态RAM变量并将其初始化为0以外的值.

有趣的是,当我直接传递大小工具的一些目标文件时,我看到.data部分被报告

例:

   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
Run Code Online (Sandbox Code Playgroud)

当构成它的目标文件报告非零值时,为什么elf文件会为.data部分报告0?

仅供参考我正在研究AT91SAM7x256 Micro的嵌入式软件

编辑:

添加CFLAGS和LDFLAGS

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

LDFLAGS += -L $(CPU_DIRECTORY) -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map
Run Code Online (Sandbox Code Playgroud)

编辑#2:从对象转储中我们可以清楚地看到.data部分已经分配了数据,但是大小实用程序由于某种原因没有将其提取到 objdump链接

我正在寻找的只是获得我的RAM的确切用法我不是想弄清楚我的一个变量是否被优化了.

编辑3:更多信息显示size实用程序确实在.data部分中看到了某些内容

$ 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
Run Code Online (Sandbox Code Playgroud)

Sim*_*ter 2

我的解释是链接器脚本创建一个可加载部分,其中包含数据部分的初始值和一段将数据复制到未初始化数据部分的启动代码。

如果您想要有一个可以从只读内存运行的单个图像文件,这是必要的,因为前面没有 ELF 加载程序可以为您执行该复制。

通常,这仅在节到段的映射中完成(即使用节>放置命令在链接描述文件中排列输出节),而不是通过映射输入节两次,但这当然也是可能的。

使用数字非常准确:文本大小是所需的闪存空间量,BSS 大小是所需的 RAM 量。初始化数据被计数两次,一次为Flash中的初始数据,一次为RAM中的可修改数据。