1. 问题现象与背景解析

在基于Keil MDK和Arm Compiler 5的开发环境中，当使用RTX5实时操作系统时，开发者可能会遇到一个棘手的调试问题：尽管已经按照手册要求，通过attribute参数为线程等OS对象指定了自定义控制块（control blocks），甚至使用了section属性将这些控制块放入特定内存段，但在启动调试会话后：

1. Component Viewer窗口中无法显示这些RTX5对象
2. Call Stack + Locals窗口中也看不到线程信息

这种情况会严重影响调试效率，因为开发者无法直观地观察线程状态、堆栈使用等关键运行时信息。我曾在一个电机控制项目中亲历此问题——当系统出现死锁时，由于无法查看线程状态，花了整整两天时间才定位到问题根源。

2. 问题根源深度剖析

2.1 调试信息的获取机制

μVision调试器通过一个名为"os_cb_sections"的特殊对象来获取RTX5的调试信息。这个对象具有以下特点：

• 仅被调试器引用，不影响实际程序运行
• 包含指向各个OS控制块的内存位置信息
• 需要保持存在于最终生成的镜像文件中

2.2 符号被优化的根本原因

Arm Compiler 5的链接器在优化时会进行"无用符号消除"（Dead Code Elimination），而"os_cb_sections"由于：

1. 不被任何程序代码直接引用
2. 没有显式声明为必须保留的符号
3. 默认链接脚本中未特殊处理

导致其在最终生成的二进制镜像中被错误移除。这就解释了为什么尽管程序能正常运行，调试器却无法获取OS对象信息。

3. 解决方案与实施细节

3.1 强制保留关键符号

在Options for Target → Linker → Misc Controls选项中添加：

--keep=os_cb_sections

这个链接器选项的作用是：

• 明确告知链接器保留指定符号
• 即使符号未被引用也不进行优化
• 不影响代码大小和执行效率

3.2 完整操作步骤

1. 在μVision中右键点击项目 → Options for Target
2. 选择Linker选项卡
3. 在Misc Controls输入框中添加--keep=os_cb_sections
4. 点击OK保存配置
5. 执行Rebuild All重新编译项目
6. 启动调试会话验证效果

重要提示：修改后必须执行完整重建（Rebuild All），增量编译可能不会更新链接器行为。

3.3 版本兼容性说明

这个问题在RTX5的不同版本中存在差异：

• 5.3.0-5.5.0：需要手动添加--keep选项
• 5.5.0+：内核实现改进，不再需要此操作

可以通过查看RTX_Config.h中的OS_VER宏确认当前使用的版本：

#define OS_VER 5U // RTOS version

4. 进阶调试技巧与问题排查

4.1 验证符号是否保留

在map文件中搜索"os_cb_sections"确认：

1. 编译完成后查看生成的.map文件
2. 搜索"os_cb_sections"符号
3. 确认其出现在"Global Symbols"部分

示例map文件片段应包含：

Global Symbols os_cb_sections 0x20000000 Data 4 main.o

4.2 常见问题排查表

4.3 多工程协作时的注意事项

在大型项目中使用RTX5时还需注意：

1. 确保所有子工程都添加--keep选项
2. 统一各模块的RTX5版本
3. 检查分散加载文件中相关section的定义

5. 原理延伸：链接器优化机制

5.1 Arm Compiler 5的链接优化

Arm Compiler 5采用的链接器会执行以下优化：

1. 静态分析符号引用关系
2. 移除未被引用的数据和代码段
3. 合并相同内容的段
4. 优化符号表大小

5.2 保留符号的多种方式

除了--keep选项外，还可通过以下方式保留符号：

1. 在代码中使用__attribute__((used))
2. 修改分散加载文件添加UNINIT段
3. 使用--no_remove全局禁用优化

但针对RTX5调试，--keep是最精准和推荐的方式。

6. 工程实践建议

基于多个项目的实战经验，我总结出以下最佳实践：

1. 版本控制配置：将--keep=os_cb_sections直接写入工程模板，新项目自动包含
2. 文档注释规范：在链接器选项处添加注释说明：

// Required for RTX5 debugging visibility --keep=os_cb_sections

3. 团队知识传递：将此问题纳入新人培训清单，避免重复踩坑

在最近的一个工业HMI项目中，我们通过规范这些实践，将类似问题的排查时间从平均4小时缩短到10分钟以内。