STM32 ELF自定义段存储的版本信息运行时无法正确读取问题
核心排查方向与对应解决方案
1. 自定义段未加入链接脚本分配规则（90%概率触发）
你通过__attribute__((section()))定义的.version、.gitcommit属于自定义段，STM32CubeIDE默认生成的链接脚本（.ld）没有为这两个段分配实际的Flash运行地址，也不会将其标记为可加载段。
此时你用objdump -s -j 段名能看到段内数据，仅代表ELF文件的符号表中存储了这段内容，不代表段数据会被打包进bin固件，更不代表芯片上电后数据会映射到可访问的内存地址上。
修复方式：
打开项目对应的STM32L462链接脚本，在Flash只读段区域（通常在.rodata、.text段配置附近）添加两个段的分配规则，必须加KEEP()关键字防止段被垃圾回收：
/* 放到FLASH区域的段配置中 */ .version : { KEEP(*(.version)) } >FLASH .gitcommit : { KEEP(*(.gitcommit)) } >FLASH
CubeIDE默认开启链接器段垃圾回收（
-Wl,--gc-sections），如果不加KEEP()，链接器会判定这两个段没有有效引用，直接从最终加载镜像中删除。
2. 后处理脚本执行顺序错误
检查你的编译后Python脚本执行流，最常见的顺序错误是：
编译生成原始ELF → 先从ELF导出bin文件 → 再用objcopy更新ELF段 → 重命名bin
这种流程下导出的bin是修改前的版本，里面自然全是初始值0xffffffff，后续对ELF的修改完全不会同步到已经生成的bin中。
修复方式：
调整执行顺序为：
- 编译生成原始ELF
- 读取Git哈希、版本号文件，通过
arm-none-eabi-objcopy --update-section修改ELF对应段 - 从修改完成后的ELF导出bin/hex固件
- 对导出的固件按版本规则重命名
3. 变量被编译器优化、访问作用域错误
你当前定义的static修饰的静态变量存在两个隐患：
- 高优化等级（-Os/-O2，CubeIDE Release模式默认开）下，编译器会直接把初始值0xffffffff做常量折叠，读取变量时直接返回常量，不会到对应内存地址取实际存储的值
static修饰的变量作用域仅限当前C文件，跨文件访问时会出现地址不匹配的问题
修复方式：
修改变量定义，加volatile强制每次读取都访问内存，加used标记防止编译器优化掉变量，去掉static方便跨文件访问：
__attribute__((section(".version"), used)) volatile uint32_t version_number = 0xffffffff; __attribute__((section(".gitcommit"), used)) volatile uint32_t git_commit = 0xffffffff;
跨文件访问时在头文件添加声明即可：
extern volatile uint32_t version_number; extern volatile uint32_t git_commit;
验证修复有效性的方法
不需要反复烧录板卡，改完后两步即可确认：
- 跑完编译全流程后，执行
arm-none-eabi-objdump -h 你的固件.elf查看段列表，确认.version和.gitcommit段带有ALLOC、LOAD属性，且段地址落在STM32L4的Flash地址范围（0x08000000起始的区域）内 - 导出bin文件后，根据段地址计算在bin中的偏移（偏移 = 段地址 - 0x08000000），用二进制查看工具跳转到对应偏移，确认存储的值是你写入的版本、Git哈希，而不是初始的0xffffffff。
注：STM32L4为小端模式，若修复后读出版本号字节序错位，调整版本字段移位逻辑、Git哈希的SWAP32规则即可。
内容的提问来源于stack exchange，提问作者Almog Stern
