摘要：本文将会和读者分享LiteOS 5.0版本中Cortex-M架构的backtrace软件原理及实现，供大家参考和学习交流。
原理介绍
汇编指令的执行流程
图 1 汇编指令的执行顺序
上图1所示，ARM的汇编指令执行分三步：取值（fetch）、译指（decode）、执行（execute），按照流水线的方式执行，即当运行指令节拍m时，pc会指向n+2汇编指令地址进行取指令操作，同时会将n+1处汇编指令翻译成对应机器码，并执行指令n。
内存中栈的布局
图 2 栈在内存中的布局
LiteOS Cortex-M架构的栈布局如上图2，栈区间在内存中位于最末端，程序运行时从内存末端（栈顶）开始进行递减压栈。LiteOS的内存末端为主栈空间（msp_stack），LiteOS进入任务前的初始化过程及中断函数调用过程的栈数据保存在此区间内，主栈地址空间往下为任务栈空间（psp_stack），任务栈空间在每个任务被创建时指定，多个任务栈空间依次排列。一个任务中可能包含多个函数，每个函数都有自己的栈空间，称为栈帧。调用函数时，会创建子函数的栈帧，同时将函数入参、局部变量、寄存器入栈。栈帧从高地址向低地址生长。
寄存器数据入栈流程
ARM为了维护栈中的数据设计了两个寄存器，分别为fp寄存器（framepointer，帧指针寄存器）和sp寄存器（stack pointer，堆栈寄存器）。fp指向当前函数的父函数的栈帧起始地址， sp指向当前函数的栈顶。通过对sp寄存器的地址进行偏移访问可以得到栈中的数据内容，通过访问fp寄存器地址可以得到上一栈帧的起始位置，进而计算出函数的返回地址。由于Cortex-M没有fp寄存器，若想获得函数入口地址只能通过sp地址偏移找到lr寄存器（link register，链接寄存器，指向当前函数的返回地址），并结合函数入口的push指令计算得出。lr寄存器会在每次函数调用时压入栈中，用以返回到函数调用前的位置继续执行。函数调用执行流程引用自Joseph Yiu的《Cortex-M3 权威指南》，如下图3所示。
图 3 函数调用执行流程
如函数调用执行流程所示，程序进入一个子函数后，通常都会使用push指令先将寄存器的值压入栈中，执行完业务逻辑后再使用pop指令将栈中保存的寄存器数据出栈并按顺序存入对应的寄存器。当程序执行bl跳转指令时，pc中的值为bl指令后的第二条指令的地址，减去一条汇编指令的长度后为bl后第一条指令的地址，即lr值。程序在进入Fx1前，bl或blx指令会将此lr值保存到lr寄存器，并在进入Fx1函数时将其压入栈中。例如有如下汇编指令：
-
800780e:
6078 str r
0,
[r7, #4]
-
8007810: f
7ff ffe
0 bl
80077d
4 <test_div>
-
8007814: f
7f
9 fe
68 bl
80014e
8 <OsTickStart>
当程序执行到地址0x8007810时，在bl指令跳转到函数test_div之前，bl指令会将此时的pc地址（0x8007818）减去一条汇编指令的长度（这里为4），将计算得到的值0x8007814（本条指令仅执行到译指，尚未完成全部执行过程，返回后需重新取指）保存到lr寄存器。
实现思路
根据函数调用执行流程的原理，当程序跳入异常时，传入当前位置sp指针，通过对sp指针进行循环自增访问操作获取栈中的内容，sp指向栈顶，循环自增的边界即任务栈的栈底，由于Cortex-M使用的thum-2指令集，汇编指令长度为2字节，因此可通过判断栈中的数据是否两字节对齐及位于代码段区间内筛选出当前栈中的汇编指令地址。并通过判断上一条是否为bl指令或blx指令（b、bx指令不将lr寄存器入栈，不对其进行处理）对上一条指令进行计算。跳转指令的机器码构成如下图4所示：
图 4 thum跳转指令机器码构成
如果为bl指令地址（特征码0xf000），通过该地址中存储的机器码计算出偏移地址（原理见下图5），从而获得跳转指令目标函数入口地址，如果为blx指令（这里为blx 寄存器n指令，其特征码0x4700），由于目标偏移地址保存在寄存器中，无法通过机器码计算偏移地址，则需要根据被调用帧保存的lr地址推算其所在的函数入口地址，直到入口处的push指令。
图 5 bl指令偏移地址计算规则
设计实现分析
LiteOS在运行过程中出现异常时，会自动转入异常处理函数。LiteOS提供了backtrace函数用于跟踪函数的堆栈信息，通过系统注册的异常处理函数来调用backtrace函数实现系统异常时自动打印函数的调用栈。
设计思路
由于Cortex-M架构无fp寄存器，sp寄存器分为msp寄存器（用于主栈）和psp寄存器（用于任务栈），因此只能通过汇编指令机器码计算及lr地址自增查找函数入口处的push指令特征码计算函数入口。
详细设计
图 6 backtrace代码框架
当调用Cortex-M架构的ArchBackTrace接口时，该函数会通过ArchGetSp获取当前sp指针，如果在初始化或中断过程发生异常，sp指向msp，在任务中发生异常，sp指向psp。将获取的sp指针传入BackTraceWithSp进行调用栈分析，该函数通过FindSuitableStack函数进行栈边界确认，找到合适的任务栈边界或主栈（未区分中断栈及初始化栈）边界。再通过边界值控制循环查找次数，从而确保将对应栈空间内所有栈帧的lr地址过滤出来。最后将lr地址传入CalculateTargetAddress函数计算出lr前一条指令（即跳转指令）要跳转到的函数入口地址。
代码路径
以上代码在LiteOS 5.0版本中已经发布，核心代码路径如下：
https://gitee.com/LiteOS/LiteOS/blob/master/arch/arm/cortex_m/src/fault.c
Backtrace效果演示
图 7 除0错误用例函数
演示demo设计了一个会导致除0错误的函数（如上图图7），分别在初始化、中断、任务三个场景下调用该函数，将会触发异常并打印相应的信息，观察相应的fp（此处指函数入口地址，非栈帧寄存器的值）地址是否与实际代码的反汇编地址一致。
可以通过menuconfig菜单使能backtrace功能，菜单项为：Debug--> Enable Backtrace。同时为避免编译优化造成的影响，还需配置编译优化选项为不优化：Compiler--> Optimize Option --> Optimize None。
下面所示图中，左图为异常接管打印的日志，右图为反汇编代码。可以看到左图中出现异常的pc指令值，对应于右图中的汇编代码为sdiv r3, r2, r3，即为test_div函数中的int z = a / b代码行。左图中打印的backtrace信息，其fp值和右图中的函数入口地址一致。
任务中触发异常:
图 8 backtrace任务演示效果
中断处理函数中触发异常:
图 9 backtrace中断演示效果
初始化函数中触发异常:
图 10 backtrace初始化演示效果
结语
程序异常或崩溃时，通过backtrace可以快速定位到问题代码的程序段，是代码调试的必备利器。当与其它工具深度结合时，如与LiteOS的LMS结合时，会碰撞出更奇妙的火花，甚至可以不用分析汇编代码，直接跳转到出问题的C代码行。
对于其它架构，如LiteOS Cortex-A的backtrace实现会有差异，读者可以参考arch目录下其它架构的backtrace相应实现。
如果您对backtrace有其它疑问或需求，可以在公众号留言或者在社区参与讨论：https://gitee.com/LiteOS/LiteOS/issues。
本文分享自华为云社区《LiteOS调测利器之backtrace原理剖析》，原文作者：风清扬。
转载：https://blog.csdn.net/devcloud/article/details/113368032