LittleKernel线程切换时的栈使用分析

最新推荐文章于 2024-11-05 19:11:45 发布

星星的小屋

最新推荐文章于 2024-11-05 19:11:45 发布

阅读量1.1k

点赞数 1

文章标签：嵌入式 arm

本文链接：https://blog.csdn.net/exoskeleton/article/details/105450737

版权

本文深入分析ARM32位架构下的线程上下文切换机制，探讨了线程的保存与恢复过程，特别是在IRQ中断场景下的处理方式。详细解释了ARM32位架构中线程切换的具体实现，包括异常处理、栈空间使用以及线程结构体的初始化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文以ARM32位架构相关代码进行分析，贴的代码较少，需自己对着代码详细看。文章最下面有自己做的图，可以参考。
切入，在本文指恢复线程上下文；切出，在本文指保存线程上下文。
加电后CPU处于SVC模式。
初始化调用如下图（来自高通的Little Kernel Boot Loader Overview文档）。
LK加电后CPU入口函数调用
上图中的过程在ARM32位架构下的实现位于start.S文件中。其中在.Lstack_setup中设置各模式栈，但是这里将irq、fiq、abort、undefined、sys模式下的sp设置为0，因为lk的设计是CPU进入这几个异常后会立即切换到svc模式执行，无需这几个异常模式下的栈，svc模式的sp指向了abort_stack数组。abort_stack的定义在arch.c中，从其定义可以看出所有的cpu核的abort栈空间都位于此数组，具体的分配在arm_secondary_setup函数中（按核顺序分配）。
从mk文件中大致看出该数组大小为4096字节或1024字节。下面的分析中，一个线程比较全面的上下文保存约占100字节（如果另外保存浮点寄存器，那就更多）。

/* initial and abort stacks */
uint8_t abort_stack[ARCH_DEFAULT_STACK_SIZE *SMP_MAX_CPUS] __CPU_ALIGN;

lk_main的最后创建了一个线程（下文称为idle线程），在这个新线程中执行下一阶段的初始化引导，由函数bootstrap2实现该线程内容，lk_main之后就通过调用thread_become_idle()进入死循环。
thread_become_idle()->thread_yield()->thread_resched()并最终调用对应体系架构下的arch_context_switch(oldthread, newthread)。

保存与恢复宏定义

SRS指令，保存当前模式下的SPSR和LR到指定模式下的栈中；
RFE指令，恢复CPSR和PC，与SRS配对使用。
异常进入后，调用保存宏，切换到SVC模式下执行后面的异常处理，所有的上下文都保存在svc模式栈里，因此异常的恢复相关的宏执行时就是从SVC模式恢复到异常之前的状态。

.macro stack_align, tempreg栈8字节对齐调整，然后原sp指针压栈
.macro stack_restore, tempreg栈8字节对齐恢复
.macro vfp_save, temp1 保存并禁止浮点计算单元，其实就是保存fpexc寄存器
.macro vfp_restore, temp1恢复vfp状态到fpexc寄存器
.macro save
.macro save_offset, offset  先调整lr，再调用save宏
.macro restore
.macro saveall，与save的区别是多保存了寄存器r4~r11
.macro saveall_offset, offset先调整lr，再调用saveall宏
.macro restoreall

可以根据源码看出LK处理UND、SVC、PABORT和DABORT异常、FIQ中断均为进入死循环，这里不做讨论。

IRQ中断

arm_irq实现：

FUNCTION(arm_irq)
#if TIMESTAMP_IRQ
    /* read the cycle count */
    mrc     p15, 0, sp, c9, c13, 0
    str     sp, [pc, #__irq_cycle_count - . - 8]
#endif

    save_offset    #4

    /* r0 now holds pointer to iframe */

    /* track that we're inside an irq handler */
    LOADCONST(r2, __arm_in_handler)
    mov     r1, #1
    str     r1, [r2]

    /* call into higher level code */
    bl  platform_irq

    /* clear the irq handler status */
    LOADCONST(r1, __arm_in_handler)
    mov     r2, #0
    str     r2, [r1]

    /* reschedule if the handler returns nonzero */
    cmp     r0, #0
    blne    thread_preempt

    restore

IRQ中断的执行，其实没有使用IRQ模式的栈，使用的是SVC模式的栈。根据platform_irq的返回结果，如果不需重新调度，则原路返回，这种情况简单。但是在需要重新调度的情况下，就稍微复杂点，调用thread_preempt执行具体的调度及切换。
那么thread_preempt()都干了啥。与thread_yield()函数类似，干了2件事。

将当前的线程（即将被调度出）重新插入到线程队列（insert_in_run_queue_head()/ insert_in_run_queue_tail()）;
调用thread_resched();

thread_preempt()和thread_yield ()最终都调用了void thread_resched(void)进行切换，而该函数最终会调用与体系架构相关的arch_context_switch(oldthread, newthread);函数执行真正的切换。
所以需要关注一下arch_context_switch具体是怎么做的。取出线程结构体中指向栈的指针，然后调用arm_context_switch（以ARM为例），传入的参数就是新旧两个线程的各自上下文的指针。

void arm_context_switch(vaddr_t *old_sp, vaddr_t new_sp);
    /* context switch frame is as follows:
     * lr
     * r11
     * r10
     * r9
     * r8
     * r7
     * r6
     * r5
     * r4
     */
/* arm_context_switch(addr_t *old_sp, addr_t new_sp) */
FUNCTION(arm_context_switch)
    /* save non callee trashed supervisor registers */
    /* spsr and user mode registers are saved and restored in the iframe by exceptions.S */
    push    { r4-r11, lr }

    /* save old sp */
    str     sp, [r0]

    /* clear any exlusive locks that the old thread holds */
#if ARM_ARCH_LEVEL >= 7
    /* can clear it directly */
    clrex
#elif ARM_ARCH_LEVEL == 6
    /* have to do a fake strex to clear it */
    ldr     r0, =strex_spot
    strex   r3, r2, [r0]
#endif

    /* load new regs */
    mov     sp, r1
    pop     { r4-r11, lr }
    bx      lr

arm_context_switch做的切换工作仅是保存与恢复{ r4-r11, lr }几个寄存器，然后该函数原路返回了（此时svc_sp已发生切换），也即一路返回到exceptions.S继续执行IRQ的异常返回（此时就剩下执行restore宏了），因为IRQ异常保存的是struct iframe，所以restore宏恢复的是除{r4~r11}外的其他跟线程有关的寄存器。此过程中关于浮点寄存器的相关保存和恢复暂不介绍。为什么恢复{ r4-r11, lr }后能返回，因为恢复后，lr寄存器里保存着该线程上次被IRQ打断且在中断处理过程中调度出时的状态（进到这里），即当时这个lr寄存器指向的是arch_context_switch函数里的位置（再次强调，此时svc_sp已发生切换）。
这个过程也就表示真正保存与恢复的与线程相关的寄存器是{ r4-r11, sp, lr }和浮点寄存器而已。而其他的寄存器（r0~r3，r12）在后面恢复。
有一个需要注意的地方，调用arm_context_switch后，svc下的sp指针已改变！arm_context_switch返回以及后面的执行涉及到的压栈出栈操作均是以新切入线程的sp为基准的，后面的执行虽然在SVC模式下，但是svc_sp变成了这个新线程的sp，也即是在切入线程的上下文空间进行的操作。而进入IRQ异常后，切换到SVC并保存的那些内容实际上已经在arm_context_switch中通过保存那时的svc_sp指针到切出线程结构体的sp成员里了，也就是说切出线程的上下文空间是已经被保存，有点绕。
关于新建线程首次被切入，因为创建新线程时会调用arch_thread_initialize函数初始化相关上下文空间，在线程的栈空间的顶部分配并初始化一个上下文结构体struct context_switch_frame，由线程结构体中的sp元素指向该上下文结构体。执行arm_context_switch时不必完全要求一个类似IRQ里创建的栈内容（调用save_offset宏），首次被切入会使用该上下文恢复并执行，再往后被切出时则会将该线程的上下文保存到SVC模式栈里。

struct context_switch_frame {
    vaddr_t r4;
    vaddr_t r5;
    vaddr_t r6;
    vaddr_t r7;
    vaddr_t r8;
    vaddr_t r9;
    vaddr_t r10;
    vaddr_t r11;
    vaddr_t lr;
};

void arch_thread_initialize(thread_t *t) {
    // create a default stack frame on the stack
    vaddr_t stack_top = (vaddr_t)t->stack + t->stack_size;

    // make sure the top of the stack is 8 byte aligned for EABI compliance
    stack_top = ROUNDDOWN(stack_top, 8);

    struct context_switch_frame *frame = (struct context_switch_frame *)(stack_top);
    frame--;//上下文空间，用于首次切入

    // fill it in
    memset(frame, 0, sizeof(*frame));
    frame->lr = (vaddr_t)&initial_thread_func;//线程入口

    // set the stack pointer
    t->arch.sp = (vaddr_t)frame;//arm_context_switch使用该sp指向的上下文内容恢复线程执行

#if ARM_WITH_VFP
    arm_fpu_thread_initialize(t);
#endif
}

初始化时线程的t->arch.sp = (vaddr_t)frame;指向自己的栈空间。
关于idle线程，第一阶段boot代码被当做了一个线程（idle线程，lk_main最初调用thread_init_early();创建的，就是static thread_t _idle_thread;），lk_main最后是创建新线程（bootstrap2，用于执行第2阶段引导工作）并进行一次调度，自身这个idle线程上下文就被保存到svc栈里，然后bootstrap2被首次切入并执行。后续如果idle线程再次被切入了，则会从arm_context_switch逐级返回到lk_main并继续调用thread_become_idle();然后就进入死循环了。问题是idle首次切出时被保存完整了吗，因为arm_context_switch里只保存了{ r4-r11, sp, lr }啊，看来r0~r3和cpsr等其他无关痛痒。
注意，idle线程第一次被切换出去时arm_context_switch才真正第一次设置idle线程结构体里的sp指针为当前初始化代码的svc的栈空间，此处为保存的idle线程的上下文内容，包括lr等，实际上也只有{ r4-r11, lr }而已，这不妨碍idle线程重新被扇入时能够被继续顺利执行。Idle线程结构体里的stack元素也从未被设置过，也不需要。实际上idle线程的栈就是abort_stack数组。此后，arm_context_switch切入新线程（bootstrap2）在arm_context_switch的最后会返回到新线程的入口处开始执行（仅线程首次切入是这样）。
svc模式下栈的使用，自idle线程被切出保存的空间向下，是其他被切出的线程的被保存的上下文空间，每段空间包含三部分内容：1、IRQ入口保存的部分；2、从thread_preempt向下逐级调用至arm_context_switch函数产生的临时变量占用的空间；3、arm_context_switch压入的{ r4-r11, sp, lr }。文后有图示例。随着这三部分内容被保存（对应线程被切出），svc栈就向下递减，只要有更新的线程继续被切出保存，则该svc栈空间就继续递减。如果有一个线程被切入，那么它对应的那部分空间就被释放了，然而被切入的线程不一定是按顺序释放的，这就造成了被释放的空闲空间不一定是连续的。只有所有其他线程（idle除外）被释放完了，这些空间才完全变成连续的空闲空间。
总之，idle线程上下文被保存在svc栈空间，其他新建线程首次被切入前其上下文空间在自己的栈里初始化，首次被切出时就被保存到了svc的栈里，后续的切入切出涉及到的上下文都保存到了svc栈里，而且其位置可能是动态变化的。
问题
一个问题是，加入一直有线程被切出，则会占用svc空间保存对应的上下文，那么会不会存在svc栈空间耗尽的情况呢？
另一个问题是，如果idle线程再次被切入，但是其上下文空间下面紧挨着的另一个线程t的空间仍被占用（未被释放或切出），idle后续执行的函数调用会不会因压栈而污染相邻线程t的上下文空间？
可能需要详细了解LittleKernel的设计以及功能定位了。应该不会出现这两个问题的。