1. 问题背景与现象分析在嵌入式开发中我们经常会遇到多个模块使用相同常量值的情况。以ARM架构为例当相同的常量出现在不同C模块中时编译器会为每个模块生成独立的literal pool文字池。但在某些特殊场景下这种默认行为可能导致严重问题。最近在Keil MDK环境下使用Arm Compiler 6时发现一个有趣现象当两个模块分别位于不同的执行区域execution region时即使使用了相同的常量值如0x12345678链接器仍会尝试合并这些literal pool。以下是具体表现/* main.c */ int main(void) { return 0x12345678; } /* optional.c */ int optional(void) { return 0x12345678; }对应的scatter file配置如下LR_IROM1 0x00000000 { ER_IROM1 0x00000000 { *.o(RESET, First) *(InRoot$$Sections) .ANY(RO) } RW_IRAM1 0x20000000 { .ANY(RW ZI) } } LR_IROM2 0x00000800 { ER_IROM2 0x00000800 { optional.o(RO) } }实际生成的汇编代码显示两个模块的0x12345678常量被合并到了ER_IROM2区域; main.c中的引用 LDR r0,[pc,#940] ; 指向0x00000804 ; optional.c中的存储 0x00000804 DCW 0x5678 0x00000806 DCW 0x1234关键问题当ER_IROM2区域作为可选模块如后期下载的补丁或受硬件保护时这种跨区域的literal pool共享会导致运行时错误。2. 解决方案深度解析2.1 常规方案及其局限性最直观的解决方案是使用链接选项--no_merge_litpools完全禁用literal pool合并。但这种方法会导致代码体积显著增大在资源受限的嵌入式系统中往往不可行。实测在包含大量重复常量的项目中禁用合并可能使代码体积增加15%-30%。2.2 OVERLAY属性方案Arm链接器提供了OVERLAY区域属性原本用于处理内存覆盖场景但恰好能解决我们的问题。修改后的scatter file如下LR_IROM2 0x00000800 OVERLAY { ER_IROM2 0x00000800 { optional.o(RO) } }添加OVERLAY属性后生成的汇编代码变化明显; main.c现在有自己的literal pool 0x0000045C DCW 0x5678 0x0000045E DCW 0x1234 ; optional.c保持独立 0x00000804 DCW 0x5678 0x00000806 DCW 0x1234工作原理OVERLAY属性向链接器声明该区域可能不可用链接器会避免其他区域依赖该区域的literal pool每个模块维护自己独立的常量副本2.3 PROTECTED属性链接器≥6.15从链接器6.15版本开始PROTECTED属性的功能被扩展也可以防止literal pool共享LR_IROM2 0x00000800 PROTECTED { ER_IROM2 0x00000800 { optional.o(RO) } }与OVERLAY的区别PROTECTED仅禁止literal pool共享仍进行区域重叠检查OVERLAY同时禁用literal pool共享和区域检查3. 实现细节与注意事项3.1 内存布局验证使用OVERLAY属性后必须手动确保区域间没有意外重叠各区域大小满足需求推荐使用fromelf --text -c查看生成的map文件确认每个模块的literal pool位于预期区域没有跨区域的引用3.2 性能与尺寸权衡实测数据对比基于STM32F407项目配置方案代码尺寸最大栈使用量默认合并48.7KB1.2KB--no_merge_litpools56.2KB1.2KBOVERLAY方案50.1KB1.2KB可见OVERLAY方案在尺寸和功能间取得了良好平衡。3.3 多区域配置策略对于复杂系统建议采用分层策略核心功能区域不使用特殊属性允许合并可选模块区域使用OVERLAY/PROTECTED安全关键区域使用PROTECTED独立literal pool示例LR_CORE 0x00000000 { ER_CORE 0x00000000 { core*.o(RO) } } LR_PATCH 0x00080000 OVERLAY { ER_PATCH 0x00080000 { patch*.o(RO) } } LR_SECURE 0x00100000 PROTECTED { ER_SECURE 0x00100000 { secure*.o(RO) } }4. 常见问题排查4.1 链接错误分析问题现象Error: L6235E: More than one section matches selector解决方案检查scatter file中的模块选择器是否重复确认没有多个区域包含相同的.o文件4.2 运行时数据异常问题现象 读取常量值时得到错误数据排查步骤使用--infosummarysizes查看literal pool分布检查map文件中符号的最终地址确认没有启用不受控的优化选项4.3 版本兼容性问题问题现象 PROTECTED属性未生效解决方案确认链接器版本≥6.15使用armlink --version检查必要时升级Keil MDK5. 工程实践建议模块化设计将需要隔离的代码放在独立物理文件中属性标注在头文件中使用__attribute__((section(SEC_NAME)))显式控制布局持续验证定期检查生成的map文件实现自动化测试验证各模块独立加载能力文档记录在scatter file中添加详细注释说明各区域设计意图对于需要动态加载的模块建议采用以下模式// 在模块接口头文件中 #define MODULE_ENTRY __attribute__((used, section(MOD_ENTRY))) #define MODULE_CONST __attribute__((section(MOD_LIT))) MODULE_ENTRY int module_init(void); const uint32_t MODULE_CONST config_param 0x12345678;配套的scatter file配置LR_MODULE OVERLAY { ER_MODULE { *.o(MOD_ENTRY) *.o(MOD_LIT) } }这种设计模式可以确保明确的模块接口点自包含的常量存储清晰的加载边界