STM32F030F4中0x48000000寄存器地址在objdump中缺失的问题

• 检查编译器优化设置

  • 查看Makefile中的优化等级参数（如-O0/-O1/-O2），高优化等级可能会将常量直接嵌入指令、省略符号引用。尝试将优化等级改为-O0重新编译，再检查objdump输出。
  • 确认是否添加-fno-eliminate-unused-debug-symbols类参数，避免符号被优化清除。

• 核对常量定义方式

  • 若使用#define REG_ADDR 0x48000000，编译器会直接替换值到指令中，不会在.data段生成符号。此时需在反汇编中搜索对应指令的立即数（比如ldr r0, =0x48000000的机器码），确认地址是否实际存在于指令中。
  • 若用全局变量定义（如const uint32_t reg_addr = 0x48000000;），检查是否被分配到.rodata只读数据段而非.data段，此时objdump应在.rodata区域找到该值。

• 分析链接脚本配置

  • 查看链接脚本中.data、.rodata的内存分配范围，确认0x20000088是否属于.data段的覆盖区间。若存在自定义段配置，需排查变量是否被分配到其他段。
  • 检查段属性设置，避免本该在.data的变量被误分配到未初始化的.bss段，或被链接器合并到其他段。

• 反汇编追踪地址来源

  • 定位访问SRAM地址0x20000088的汇编指令，确认该地址的值是从Flash加载而来，还是运行时动态计算的。
  • 检查启动文件中的.data段复制逻辑，确认复制范围是否覆盖0x20000088，避免因复制范围遗漏导致变量未正确初始化。

• 验证Makefile编译链接参数

  • 确认是否添加-g参数生成调试信息，让objdump能显示更详细的符号与段关联信息。
  • 检查链接时是否指定了正确的STM32F030F4链接脚本，避免误用其他芯片脚本导致内存分配错误。

内容的提问来源于stack exchange，提问作者Marcell Juhász