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

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

当我使用我的工具链(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

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

我知道我的代码正在使用和初始化静态RAM变量到非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

有趣的是，当我直接传递size工具时，一些正在被链接的对象文件会被报告。data部分

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?

当使其成为.data部分的对象文件报告非零值时，为什么elf文件会报告0 ?

FYI I am working on embedded software for a AT91SAM7x256 Micro

我正在为AT91SAM7x256微处理器开发嵌入式软件。

edit:

编辑:

adding the CFLAGS and LDFLAGS

添加CFLAGS和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

编辑#2:从对象转储中我们可以清楚地看到.data部分有分配给它的数据，但是大小实用程序并没有因为某些原因而选择它。

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.

我所要做的就是得到RAM的确切用法我并不是想弄清楚我的一个变量是否被优化了。

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

编辑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

2 个解决方案

#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.

如果您想要一个可以从只读内存运行的图像文件，这是必要的，因为前面没有ELF加载程序，那么它将为您执行该拷贝。

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.

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

#2

Your .data section have the CODE attribute set, and this confuses "arm-none-eabi-size". The size of the .data section is incorrectly added to the total text size instead of the data size.

您的.data部分拥有代码属性集，而这将混淆“arm-none-eabi-size”。.data部分的大小被错误地添加到整个文本大小中，而不是数据大小。

My guess is that you have some code that is stored in flash but is copied to ram at run time such as a fast interrupt handler or flash reprogramming that must run from RAM. This will set the CODE attribute for the data segment, and "size" believes that all of .data is text.

我的猜测是，您有一些代码存储在flash中，但在运行时被复制到ram中，比如快速中断处理程序或必须从ram中运行的flash重新编程。这将设置数据段的代码属性，“size”认为所有的.data都是文本。

#1