数组与结构体初始化差异及crt0补丁生效原因咨询

问题背景 #

项目从Pulpino切换到CV32内核后，出现静态存储结构体初始化异常：静态结构体的指针成员初始值为0，但静态数组初始化正常；仅栈上定义的结构体初始化正常。修改crt0.S中bss清零的起始地址，将la a0, _edata替换为la a0, _bss_start后问题解决。

1. 静态数组与结构体初始化差异的原因 #

核心差异在于两者的初始化值类型和编译/链接处理逻辑不同：

• 静态数组：text_in_data、text_in_data2的初始化值是编译期可确定的常量，链接器会直接将这些常量写入Flash的.data段镜像中。crt0启动时会把Flash中的.data镜像完整拷贝到RAM的.data区域，因此数组能正常保留初始化值。
• 静态结构体：text_in、text_in2等的初始化值是其他变量的地址，属于运行时重定位符号——编译阶段无法确定最终内存地址，Flash的.data镜像中对应addr成员的位置只是占位符（通常为0）。crt0需要在拷贝.data后执行重定位操作，将正确的地址写入该位置。但未修复的crt0错误地将结构体所在的.data区域纳入了bss清零范围，覆盖了重定位后的地址值，导致初始值为0。
• 栈上结构体：text_in3是在main函数运行时才初始化的，直接使用当前已确定的变量地址，不受crt0启动阶段的清零操作影响，因此初始化正常。

2. crt0补丁生效的具体原因 #

正常的嵌入式系统启动流程中，crt0需要完成两个关键操作：

1. 把Flash中存储的.data段镜像拷贝到RAM的.data区域（存放已初始化的静态变量）；
2. 把RAM的.bss段清零（存放未初始化/零初始化的静态变量）。

未修复版本的问题 #

原crt0中错误地将bss清零的起始地址设为_edata（.data段的结束地址），结合链接脚本中重复定义.bss段的问题，导致清零范围意外覆盖了.data段的末尾区域——恰好是静态结构体所在的内存地址，把待重定位的addr成员清为0。

补丁的作用 #

将清零起始地址改为_bss_start后，清零操作被严格限制在真正的.bss段范围内（从_bss_start到_bss_end），不再触及.data段的初始化变量。此时crt0的重定位操作能正常将正确的变量地址写入结构体的addr成员，结构体初始化恢复正常。

额外建议 #

链接脚本中重复定义了.bss段，这可能导致内存区域的地址计算混乱，建议合并.bss段的定义，统一管理符号：

.bss :
{
    . = ALIGN(4);
    _bss_start = .;
    *(.bss)
    *(.bss.*)
    *(.sbss)
    *(.sbss.*)
    *(COMMON)
    . = ALIGN(4);
    _bss_end = .;
    _end = .;
} > dataram

内容的提问来源于stack exchange，提问作者Guillaume D