1. 背景
当系统进入异常时，通常会进入异常对应的处理函数，当系统中存在非法操作时，比如除0、非对齐访问、爆栈，此时便会触发 hardfault 异常，一般情况下，hardfault 中是个 while(1)，此时系统中存在非法操作，就会被这个 while(1) 永远挂着，但是此时需要查找为什么系统崩了，怎么查？从何处查？通常进入到 hardfault 后调用栈也没了，新手玩家会很头疼，不知从何处查起。因此，系统宕机时，必须拥有足够的信息帮助我们分析宕机原因
2. 基础知识
- cm 架构，响应异常的第一个行动，就是自动保存现场的必要寄存器信息，依次会把 psp、pc、lr、r12、r3-r0 由硬件自动压入适当的栈中
- cm 架构是双栈指针设计，当上下文环境是线程环境时，栈指针是psp，当上下文是中断环境时，栈指针为 msp，双栈指针设计天生为 os 而来，这样保证了线程环境与中断环境隔离
- cm 架构的栈是向下生长的
- 任意时刻，仅存在一个 sp 指针，要么是 psp，要么是 msp
3. rt-thread 构造栈帧
-
在 rt-thread 中每个线程拥有独立的栈空间，栈空间可以是静态的，也可以是动态申请的，栈就是一片连续的内存。
struct exception_stack_frame { rt_uint32_t r0; rt_uint32_t r1; rt_uint32_t r2; rt_uint32_t r3; rt_uint32_t r12; rt_uint32_t lr; rt_uint32_t pc; rt_uint32_t psr; }; struct stack_frame // 架构不同，栈帧的大小也不同 { /* r4 ~ r11 register */ rt_uint32_t r4; rt_uint32_t r5; rt_uint32_t r6; rt_uint32_t r7; rt_uint32_t r8; rt_uint32_t r9; rt_uint32_t r10; rt_uint32_t r11; struct exception_stack_frame exception_stack_frame; }; /* 初始化线程栈，构造栈帧 */ rt_uint8_t *rt_hw_stack_init(void *tentry, void *parameter, rt_uint8_t *stack_addr, void *texit) { struct stack_frame *stack_frame; rt_uint8_t *stk; unsigned long i; stk = stack_addr + sizeof(rt_uint32_t);// 栈顶，连续空间的最高地址 stk = (rt_uint8_t *)RT_ALIGN_DOWN((rt_uint32_t)stk, 8); stk -= sizeof(struct stack_frame);// 向下偏移 sizeof(struct stack_frame) 个大小 stack_frame = (struct stack_frame *)stk; /* init all register */ for (i = 0; i < sizeof(struct stack_frame) / sizeof(rt_uint32_t); i ++) { ((rt_uint32_t *)stack_frame)[i] = 0xdeadbeef; } stack_frame->exception_stack_frame.r0 = (unsigned long)parameter; /* r0 : argument */ stack_frame->exception_stack_frame.r1 = 0; /* r1 */ stack_frame->exception_stack_frame.r2 = 0; /* r2 */ stack_frame->exception_stack_frame.r3 = 0; /* r3 */ stack_frame->exception_stack_frame.r12 = 0; /* r12 */ stack_frame->exception_stack_frame.lr = (unsigned long)texit; /* lr 线程退出时，将执行线程*/ stack_frame->exception_stack_frame.pc = (unsigned long)tentry; /* entry point, pc，线程切换时，进入到用户线程函数 */ stack_frame->exception_stack_frame.psr = 0x01000000L; /* PSR */ /* return task's current stack address */ return stk; } -
为什么要构造一个栈帧？
一个线程初始化完成后，怎样才能进入到线程处理函数中？是由调度器来决定的，调度器选择切换到当前时刻已经就绪的最高优先级的线程，便会手动触发一个 Pendsv 异常，进入 Pendsv 异常时，会将被切线程的上下文保存，将要执行的线程的上下文恢复到寄存器中。通过反推法，如果没有上述构造的初始栈上下文，怎么恢复到寄存器中呢？所以，构造出来一个栈帧后，将上述栈帧中的内容出栈到寄存器中，pc 寄存器中被上述恢复动作赋值成 tentry 这个函数指针，此时将要执行的线程的栈指针 sp（指向栈顶，由于该程线程首次执行，又执行了 push 操作） 更新给 psp，当异常结束返回时，就跳到了线程的处理函数中。如果线程返回了，该线程将永远不会被得到执行，因此，还需给线程收尸，也就是将该线程占用的资源给释放掉，执行构造栈帧时的 texit 函数，此函数地址在 Pendsv 异常处理函数中 push 到了 lr 寄存器中，当函数返回时，必然执行该函数。收尸动作，发生在 idle 线程中，系统空闲时，将这些僵尸线程给释放掉。
-
rt-thread 切换线程细节
rt-thread 切换线程时，进入PendSv 异常前，psp 此时是被切线程的栈顶，此时硬件自动压入 8 个寄存器的值，还需手动将剩余寄存器压入此线程对应的栈中，由于该线程需要让出处理器的使用权，因此需要将该线程的上下文环境给保存在栈中。
还有一个关键的步骤，被切线程的上下文已经全部保存在栈中了，此时线程控制块中的 sp 并没有更新，切线程时是根据线程控制块中的 sp 来切的，因此，还需将 psp 的值更新回线程控制块中的 sp 。此时该线程的上下文被保存在栈中了，同时该栈的栈顶也被保存在了线程控制块中，下次恢复上下文时，就有能力恢复了。
4. rt-thread 中 HardFault_Handler
-
rt-thread 将 HardFault_Handler 重写了，删除掉了毫无意义的 while(1)，加入了更多的信息
IMPORT rt_hw_hard_fault_exception EXPORT HardFault_Handler HardFault_Handler PROC ; get current context TST lr, #0x04 ; if(!EXC_RETURN[2]) ITE EQ MRSEQ r0, msp ; [2]=0 ==> Z=1, get fault context from handler. MRSNE r0, psp ; [2]=1 ==> Z=0, get fault context from thread. STMFD r0!, {r4 - r11} ; push r4 - r11 register STMFD r0!, {lr} ; push exec_return register # 压入lr的值来判断异常发生在线程中还是在中断中 TST lr, #0x04 ; if(!EXC_RETURN[2]) ITE EQ MSREQ msp, r0 ; [2]=0 ==> Z=1, update stack pointer to MSP. MSRNE psp, r0 ; [2]=1 ==> Z=0, update stack pointer to PSP. PUSH {lr} BL rt_hw_hard_fault_exception POP {lr} ORR lr, lr, #0x04 BX lr ENDP ALIGN 4 END -
进入异常前，硬件自动压入一些寄存器到栈中，此时的 lr 寄存器中的值代表着进入异常前的环境（线程或中断），这个环境决定着栈指针是 psp 还是 msp。因此，判断这个 lr 寄存器的 bit2 是 0 还是 1 来获取进入异常前使用的是那个栈。然后将不会被硬件压栈的寄存器给压入相应栈（psp 或 msp）中，然后将该栈的栈顶更新到 r0 寄存器中，此时跳入 C 函数中打印相关信息，入参为栈顶地址
/* 成员位置严格按照压栈顺序摆放 */ struct exception_info { rt_uint32_t exc_return; // 进入异常前的环境 struct stack_frame stack_frame; // 构造的栈帧数据结构 }; void rt_hw_hard_fault_exception(struct exception_info * exception_info) { #if defined(RT_USING_FINSH) && defined(MSH_USING_BUILT_IN_COMMANDS) extern long list_thread(void); #endif struct stack_frame* context = &exception_info->stack_frame; if (rt_exception_hook != RT_NULL) // 钩子函数 { rt_err_t result; result = rt_exception_hook(exception_info); // 执行其他异常分析函数 if (result == RT_EOK) return; } rt_kprintf("psr: 0x%08x\n", context->exception_stack_frame.psr); rt_kprintf("r00: 0x%08x\n", context->exception_stack_frame.r0); rt_kprintf("r01: 0x%08x\n", context->exception_stack_frame.r1); rt_kprintf("r02: 0x%08x\n", context->exception_stack_frame.r2); rt_kprintf("r03: 0x%08x\n", context->exception_stack_frame.r3); rt_kprintf("r04: 0x%08x\n", context->r4); rt_kprintf("r05: 0x%08x\n", context->r5); rt_kprintf("r06: 0x%08x\n", context->r6); rt_kprintf("r07: 0x%08x\n", context->r7); rt_kprintf("r08: 0x%08x\n", context->r8); rt_kprintf("r09: 0x%08x\n", context->r9); rt_kprintf("r10: 0x%08x\n", context->r10); rt_kprintf("r11: 0x%08x\n", context->r11); rt_kprintf("r12: 0x%08x\n", context->exception_stack_frame.r12); rt_kprintf(" lr: 0x%08x\n", context->exception_stack_frame.lr); rt_kprintf(" pc: 0x%08x\n", context->exception_stack_frame.pc); if(exception_info->exc_return & (1 << 2) ) // bit2 为 1，表示线程环境 { rt_kprintf("hard fault on thread: %s\r\n\r\n", rt_thread_self()->name); #if defined(RT_USING_FINSH) && defined(MSH_USING_BUILT_IN_COMMANDS) list_thread(); #endif } else { rt_kprintf("hard fault on handler\r\n\r\n"); } #ifdef RT_USING_FINSH hard_fault_track(); #endif /* RT_USING_FINSH */ while (1); } -
根据上述打印信息结合相应反汇编，就能够找到 hardfault 前正在执行的那一句代码，同时，函数发生调用时，返回地址也被压入到相应栈中，因此，根据这些基础信息，还有一定的处理空间，可通过大神写的cmbacktrace软件包进行自动化分析函数调用栈。
-
掌握系统宕机时的处理思路才是关键点，需要对 cm 架构的处理器有一定的理解
5. 手动分析
首先根据进入异常前的环境，确定是那个 sp，然后将该 sp 的值复制到内存查找窗口，查找 sp 指向的内存中的 pc 值（由于硬件会自动压栈），然后在反汇编中根据这个 pc 的值就能够找到发生异常前执行的汇编指令
为什么上图中红色下划线处是 pc 呢？需要根据硬件自动压栈的寄存器的数量以及顺序确定，不同处理器不同
2690
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
