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
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} # 压入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 架构的处理器有一定的理解
这个支持cortex-a7核吗?
如果不支持,在cortex-a7怎么才能实现?谢谢!