网站怎么做全屏的,网站策划怎么做内容,天娇易业网站建设公司,奥尔马手表官方网站记一次调试过程
这是一个在 arm 架构上的 RTOS 上的调试过程。问题现象为使用 thumb 指令集的 libgcc 库的情况下#xff0c;浮点运算随机出错。经过一番追踪调试#xff0c;逐步缩小问题范围#xff0c;最后定位问题#xff0c;成功解决。
场景
在某款的国产 RTOS 上浮点运算随机出错。经过一番追踪调试逐步缩小问题范围最后定位问题成功解决。
场景
在某款的国产 RTOS 上由于客户应用需要使用了thumb 指令集编译的 libgcc 的库导致了同时运行了 arm 指令集和 thumb 指令集的代码。原本的 RTOS 未设计运行 thumb 指令的代码也没有严格测试过所以本次暴露了浮点运算偶尔出错的问题。
测试代码
客户精简过的暴露问题代码如下
unsigned long long ulTa 0x100;
unsigned long long ulTb 0x2001;
double dRea, dReb;
double dRes;while (1) { (double)ulTa;dReb (double)ulTb;dRes dRea / dReb;if ((dRea 0.0) || (dReab 0.0) || (c 0.01f)) {printf(error!!\r\n);}}这段代码的逻辑是强转了两个 unsigned long long 类型然后进行除法运行最后判断各个变量的结果是否符合预期否则就报 error。
问题分析
抓取问题中的关键点
和浮点运算有关是不是我们的RTOS对于浮点运算的寄存器没有处理好简单的代码反复运行只是偶尔出问题而不是固定每次出问题那么考虑其他外部的影响首先考虑的是中断。
问题调试
bug调试的指导思想是仔细观察问题剖析问题提出怀疑一些原因并修改代码验证。
步骤1 剖析问题
靠近问题的实质分析问题既然计算出错那么看看出错的时候的变量是什么样的。经过一些调试打印发现 3 个 double 类型的变量都出错过。出错的时候打印这些变量对应地址存储的值发现这些内存的值有 0 存在。因为 double 变量使用 8 bytes 的空间存放的这些空间里存放的不是实际值而是分符号位指数位等。 根据这个现象我有理由怀疑是某些时候的强转没有成功。
步骤2 证明和中断的相关性
进行关中断测试在关闭中断的情况下长时间跑了测试时间足够长发现并没有出错。那么证明的确和中断有关系。
步骤3 证明测试代码的逻辑是没有问题
排查其他问题使用 arm 指令集的 libgcc 进行测试使用同样的代码时间足够长也没有出错。那么证明测试代码的逻辑是没有问题的。
陷入了第一个瓶颈
确定中断有问题那么推测偶尔出问题肯定是恰好某个时刻的中断踩到了特殊位置。修改代码关注是否是中断返回立即出错打印分析被中断打断处的指令观察是否是固定的某个指令。经过漫长的调试观察到的确有规律。 分析长时间的出错前的 PC 指针的位置很多是靠近 thumb 指令集里面的 IT block 指令。必须敏锐地抓住这个点。类似下面的 it eq 指令。
001007d4 __aeabi_ul2d:1007d4: ea50 0201 orrs.w r2, r0, r11007d8: bf08 it eq1007da: 4770 bxeq lr1007dc: b530 push {r4, r5, lr}1007de: f04f 0500 mov.w r5, #01007e2: e00a b.n 1007fa __aeabi_l2d0x16简化问题
看手册学习 it block 指令。 // 学习过程不表
证明是 it 指令的问题
调试指导思想是缩小问题的范围 想办法直接运行这个指令观察是否出错。我使用内联汇编实现使用伪代码解释代码逻辑
r1 0x10;
r2 0x10;
r3 0x20;
r4 0x40;r4 r4 - r2; //运行后 r4 0x30// itte ge , 上一行指令会改变 cpsr 的 flag 标志位
// 若 ge: r1 r1 (r4 1) //运行后 r1 0x70;
// 若 ge: r2 r2 0x10;
// 若 lt: r4 r4 0x10;代码如下
__attribute__((target(thumb))) void thumb_ins(void);
void thumb_ins(void) {int ia 0;int ib 0;int ic 0;int cnt 0;while (1) {ia 0;ib 0;ic 0;asm volatile (mov r1, #0x10);asm volatile (mov r3, #0x20);asm volatile (mov r2, #0x10);asm volatile (mov r4, #0x40);asm volatile (subs r4, r4, r2);asm volatile (itte ge);asm volatile (addge.w r1, r1, r4, lsl #1);asm volatile (addge r2, r2, #0x10);asm volatile (addlt r4, r4, #0x10);asm volatile (mov %0, r1 : r (ia));asm volatile (mov %0, r2 : r (ib));asm volatile (mov %0, r4 : r (ic));if ((ia ! 0x70) || (ib ! 0x20) || (ic ! 0x30)) {printf(error!!!);printf( r1 [0x%x] r2 [0x%x] r4[0x%x]\r\n, ia, ib, ic);}if (cnt 9000000) {printf( r1 [0x%x] r2 [0x%x] r4[0x%x]\r\n, ia, ib, ic);cnt 0;}}
}经过运行测试这个代码运行时也会打印出 error关闭中断进行测试则运行不会打印 error。则完全证明了是 it 指令执行的问题。并且发现了出错时 it block 控制的条件允许代码全部没有执行包括2条判断条件相反的指令都没有执行。
陷入了第二个瓶颈 分析 it 指令执行出错的原因
arm 手册上关于这个 it 指令从异常返回的描述 On a branch or an exception return, if PSTATE.IT is set to a value that is not consistent with the instruction stream being branched to or returned to, then instruction execution is CONSTRAINED UNPREDICTABLE. 我们需要关注到异常返回的地址和异常返回时 PSTATE.IT 的标志状态。
经过调试分析已经确认我们的 RTOS 在异常保存上下文中 cpsr 的值是正确的。使用 msr 将其恢复也是正确的。也确认了我们RTOS配置的返回地址也是正确的。满足手册中提到的注意事项问题陷入僵局。试图对比 Linux 源码中的异常保存和恢复过程中对于 thumb 指令是否有特殊处理然而并没有收获。
问题突破
经过艰难的调试之后终于有了新的突破 我们知道在异常返回时是由硬件自动将 spsr 寄存器中的值恢复到 cpsr。我在设置PC跳转之前读出 spsr 的值保存到内存中然后有了惊人的发现此时 spsr 寄存器中的内容和上下文结构体中的值不一致而且是关键的 IT block 的信息丢失。那么断定是恢复 spsr 的时候出错了。 经过简单调试和 Linux 进行对比发现了问题的根源。
问题解决
我们的 RTOS 恢复 spsr 使用的指令为 msr spsr, r1 编译生成的指令为 83ce0ae8: e169f001 msr SPSR_fc, r1。而 Linux 使用 msr spsr_cxsf, r1 编译生成的指令为 83ce0ae8: e16ff001 msr SPSR_fsxc, r1。我的 RTOS 在恢复 spsr 中丢失了关键的 s 和 x 域的内容
c 指 CPSR中的control field ( PSR[7:0])f 指 flag field (PSR[31:24])x 指 extend field (PSR[15:8])s 指 status field ( PSR[23:16]) 而恰好 IT block 信息存放在 [26:25] [15:10]
IT[1:0], bits [26:25]
IT block state bits for the T32 IT (If-Then) instruction. See IT[7:2] for explanation of this field.
IT[7:2], bits [15:10]
IT block state bits for the T32 IT (If-Then) instruction. This field must be interpreted in two parts. • IT[7:5] holds the base condition for the IT block. The base condition is the top 3 bits of the
condition code specified by the first condition field of the IT instruction.
• IT[4:0] encodes the size of the IT block, which is the number of instructions that are to be
conditionally executed, by the position of the least significant 1 in this field. It also encodes the value of the least significant bit of the condition code for each instruction in the block.
The IT field is 0b00000000 when no IT block is active.调试经验总结
分析问题缩小问题范围敏锐观察抓住灵感验证寄存器的值是否正确不能读中间状态必须紧贴使用之前进行验证相信硬件在计算机的世界没有上帝
