RISC-V架构异常处理与栈回溯分析（二）

        之前的文章RISC-V FreeRTOS异常处理及任务切换分析（基于qemu+gdb跟踪调试）_Dingjun798077632的博客-CSDN博客中，有提到FreeRTOS\Source\portable\GCC\RISC-V\portASM.S文件中通过宏portcontextSAVE_CONTEXT_INTERNAL保存上下文代码有点漏洞：portcontextSAVE_CONTEXT_INTERNAL最后将sp保存到pxCurrentTCB->pxTopOfStack中，在创建任务和调用vTaskStartScheduler()之前pxCurrentTCB必然是个空指针，此时触发异常处理，跳转到异常函数处理入口freertos_risc_v_trap_handler处执行，通过宏portcontextSAVE_CONTEXT_INTERNAL保存上下文又会触发异常，如此反复。这样上一篇文章RISC-V架构栈帧分析与栈回溯实现_Dingjun798077632的博客-CSDN博客中增加的栈回溯等相关代码在启动过程前半部分不起效，但实际开项目中，启动过程需要做大量初始化动作，启动过程是相对比较复杂，比较容易出错的，为方便以后问题调试，最好是能够解决该问题，下面就该问题分析。

异常处理问题验证

        首先，我们先验证上面提出的问题是否存在，还是基于之前的文件FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\main_blinky.c，在main_blinky函数中xTaskCreate之前调用test_fun_c，从而触发非法指令异常，代码如下：

还是用asm volatile(".word 0x1234567");触发异常

        编译后启用gdb调试，在freertos_risc_v_trap_handler和synchronous_exception函数入口处设置断点，运行结果如下：

        对照反汇编代码可以看到，第一次触发异常时mepc为0x80000660刚好为test_fun_b中的非法指令：

        继续运行到portcontextSAVE_CONTEXT_INTERNAL保存上下文时又触发异常，触发异常时的mepc为0x8000398c（实际上mepc并不一定指向对应的sw指令位置，Load和Store一般属于非精确异常，上一篇文章中已解释），对照反汇编和代码，刚好是想pxCurrentTCB指针保存数据时：

        如上所示，在异常处理保存上下文过程中，又触发异常，导致再次跳回到异常入口处，又保存上下文，如此不断循环，无法正在运行到接下来的synchronous_exception异常处理函数处。整个现象和之前的推测完全一直。

异常处理问题修改

        portcontextSAVE_CONTEXT_INTERNAL保存上下文数据基本都是放入触发异常时的栈中，只有最好需要把sp指针，保存到另一个位置，之后切换到中断栈（前面的文章中已经分析过了），这样也就是只要在启动过程中准备一个位置存放sp指针就可以。

之前文章中分析启动过程中，有提到FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\start.S中设置的初始化sp指针为_stack_top，_stack_top在fake_rom.lds链接脚本中定义的。

链接脚本FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\fake_rom.lds

        _stack_top为栈的高地址，我们增加一行_stack_end = .;用于标记栈的低地址，之后用该地址做为上文的启动过程的异常处理portcontextSAVE_CONTEXT_INTERNAL保存sp指针的地址（栈向下增长，也就是从_stack_top位置递减，_stack_end位置不会被用的，除非设置的栈太小，栈要溢出了）。通过tp寄存器（之前分析过，riscv64-unknown-elf-gcc编译器中没使用tp寄存器），刚启动初始化把tp初始化为_stack_end的地址，在运行到xPortStartFirstTask（启动第一个任务，也就是开启任务调度）时把tp设置为pxCurrentTCB。portcontextSAVE_CONTEXT_INTERNAL保存上下文时，时直接将sp值保存到tp指针指向的内存。同时在函数vTaskSwitchContext()切换pxCurrentTCB指针时，更新tp指针。

代码修改后代码如下，宏RISC_V_START_TRAP_HANDLER中为新增的代码：

1. 修改FreeRTOS\Demo\RISC-V-Qemu-virt_GCC\start.S文件，将pxCurrentTCB指向_stack_end地址：

2. FreeRTOS\Source\portable\GCC\RISC-V\portContext.h修改，用tp代替pxCurrentTCB：

3. FreeRTOS\Source\portable\GCC\RISC-V\portASM.S修改，启动调度时，设置tp=pxCurrentTCB，增加一个汇编函数processed_switchcontext，vTaskSwitchContext中调用该函数更新tp指针

4. FreeRTOS\Source\tasks.c中，vTaskSwitchContext调用processed_switchcontext更新tp指针：

     

        接着修改上一篇文章中增加的freertos_risc_v_application_exception_handler函数，在if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED )的else中增加如下代码： 

void freertos_risc_v_application_exception_handler(UBaseType_t mcause, UBaseType_t mepc, 
	UBaseType_t mtval, UBaseType_t mstatus, StackType_t * pxTopOfStack)
{

   ... ...
    if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED ) 
    {
    ... ...
    } 
    else 
    {
				xprintf("The start bactrace:\n");

	extern UBaseType_t _stack_end[];
	extern UBaseType_t _stack_top[];

	    xprintf("Ther startup stack_end:%p, StackTop:%p\n",  _stack_end, _stack_top);
#if 0
        while ((fp > _stack_end) && fp < _stack_top) {
            xprintf("fun%d: FramePointer:0x%lx\tReturnAddr:0x%lx\n", i++, fp, *(fp-1));
			fp = (UBaseType_t*)*(fp-2);
        } 	
#endif
		xprintf("Ther startup Stack:\n");
		i = 0;
		for (pStack = pxTopOfStack + portCONTEXT_COUNT; pStack < _stack_top; pStack++)
		{
			reg = *(UBaseType_t*)pStack;
			if (i++ % 8 == 0) {
				xprintf("\n%p:  0x%lx  ", pStack, reg);
			} else{
				xprintf("0x%lx  ", reg);
			}
		}

		xprintf("\n");
    }
loop:
	xprintf("Freertos risc-v application exception handler end\n");
	//while(1);
}

修改后测试

        修测试改代码，在函数main_blinky()和，xTimerCreateTimerTask主动触发两个异常。上面freertos_risc_v_application_exception_handler() 函数最后的while(1)去掉了，也就是退出异常时，回到触发异常时的pc+4位置继续执行。

FreeRTOS\Source\timers.c

        编译运行,

        可以看到第一次触发异常在main_blinky中，推出异常处理后打印了“Hello main_blinky”，接着第二次触发异常，

        测试结果符合预期，可以根据栈数据对照汇编找出函数调用关系。退出异常处理后，创建的两个任务正常运行。

        修改后的代码发生中断和异常时，portcontextSAVE_CONTEXT_INTERNAL处理，保存sp指针时，相对于先原来的代码少了一条load指令，也就是保存上下文和恢复上下文处理更快了。