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

标签 c linker embedded 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

我知道我的代码正在使用静态 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

为什么 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

编辑#2: 从对象转储中我们可以清楚地看到 .data 部分有分配给它的数据,但 size 实用程序由于某种原因没有选择它 objdump link

我正在寻找的只是获得我的 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

最佳答案

我的解释是,链接描述文件创建了一个单独的可加载部分,其中包含数据部分的初始值和一段将数据复制到未初始化数据部分的启动代码。

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

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

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

关于c - 为什么 arm-none-eabi-size 报告 .data 部分为 0,即使我使用的是已初始化的 RAM?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9725268/

相关文章:

c - .bss 与 .data : static q32 vs static int

c++ - 键入强制转换文字有意义吗?

c++ - 表示小于 1 的最大 float

c - 为什么指向一个超出有效对象的位置对于指针来说是可以接受的?

c++ - 我如何组织 C++ 代码而不用过多考虑某些内容是否已模板化?

c++ - 如何链接到 cpp-netlib

我们能否将 CUDA 或 OpenCL 的速度与 CPU 性能进行比较?

clock_gettime() 在 PC 上运行良好,但在服务器上它会中止编译

nrf51sdk 的 Makefile

c - 全局访问和指针访问之间的差异