C Unity测试框架中Unity.NumberOfTests执行++操作未自增的原因咨询

• 内存段属性配置错误：如果Unity结构体实例被错误分配到只读存储段（比如链接脚本将全局变量段错误映射到Cortex-M4的Flash区域，或是Unity被意外加上了const修饰符），对其成员的写操作（包括自增）会被硬件静默忽略。Cortex-M4对Flash的写入需要通过专用的Flash控制器接口执行，直接执行普通写指令不会修改Flash内容。
• 编译器优化裁剪：如果编译时开启了较高优化等级（如-O2/-Os），且Unity.NumberOfTests未添加volatile修饰，编译器可能判定该变量的自增结果无后续代码依赖，直接将自增语句从生成的机器码中裁剪掉。你可以查看对应代码行的反汇编，确认是否存在实际的内存读写指令。
• 符号重复定义冲突：如果工程中存在多个Unity全局结构体实例（比如自己的代码里额外定义了一个同名全局变量，或是链接了多个包含Unity定义的目标文件），会出现链接符号串用的问题：Unity库代码操作的是一个实例，而GDB解析到的是另一个地址的实例，就会出现自增后看到的值没有变化的假象。可以分别在UnityDefaultTestRun函数内和自己的业务代码里打印&Unity的地址，确认是否一致。
• 内存访问越界覆盖：如果存在其他野指针、数组越界写操作，刚好会在Unity.NumberOfTests++执行后立刻重写该变量的内存地址，也会导致值看起来没有变化。
• 调试视图与实际状态不一致：你可以在GDB中直接查看Unity.NumberOfTests对应的内存地址的原始值：执行p &Unity.NumberOfTests拿到地址后，用x/1xw 地址命令查看内存实际存储的值，避免GDB的类型解析、结构体偏移计算错误导致的显示偏差。
• Qemu模拟异常：如果Qemu中对Cortex-M4的内存区域属性配置错误（比如将RAM区域标记为只读），或是Qemu本身存在模拟缺陷，也可能出现写内存操作被静默忽略的情况。

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